[VB 2008] ID ophalen na insert

[ieperlingetje]

Via Table adapters vul ik tabellen in een access database. Dit zijn relationele tabellen, en dus is het handig als ik telkens het ID kan opvragen van de net ingevoegde rij. Iemand die mij kan helpen? Google kan niet echt overweg met het zoeken naar recente visual basic versies over dit onderwerp, meestal krijg ik VBA of oude visual basic code terug, dus als iemand nog een goede site weet waar ik alle info kan vinden, gelieve dan hier ook even te melden.

[Verwijderd]

Ik geef het id zelf ook altijd mee, dus laat het niet automatisch genereren. Ik heb dan ook een tabel voor alle ID's (die gewoon elke keer worden opgehoogd in deze tabel).

[RobIII]

Verwijderd schreef op woensdag 16 juni 2010 @ 14:18:
Ik geef het id zelf ook altijd mee, dus laat het niet automatisch genereren. Ik heb dan ook een tabel voor alle ID's (die gewoon elke keer worden opgehoogd in deze tabel).

Je zult wel niet vaak met multi-user apps werken neem ik aan? Je beseft dat dit een disaster-waiting-to-happen is als je met concurrency te maken krijgt?

@TS: Met een beetje googlen moet er toch wel wat zinnigs te vinden zijn

[lier]

@@identity icm executescalar

Oeps: zie nu dat het over Access gaat...misschien het Access equivalent zoeken of een database zoals SQL server gaan gebruiken)

[ Voor 70% gewijzigd door lier op 16-06-2010 14:26 . Reden: Werk zelf (te) veel met MS SQL ]

[Snake]

C#:

// Create another Command to get IDENTITY Value
var getIdentity = new OleDbCommand("SELECT @@IDENTITY", connection);

int result = resultingID = (int)getIdentity.ExecuteScalar();

Werkt op Access. Wel in dezelfde transactie doen als je insert. Niet dat dat een probleem is met single user omgevingen maar in multiuser omgevingen kan je een verkeerd resultaat binnenkrijgen bij 2 verschillende transacties

[ Voor 40% gewijzigd door Snake op 16-06-2010 14:34 ]

[.oisyn]

RobIII schreef op woensdag 16 juni 2010 @ 14:23:
[...]

Je zult wel niet vaak met multi-user apps werken neem ik aan? Je beseft dat dit een disaster-waiting-to-happen is als je met concurrency te maken krijgt?

Nonsense, een test-and-set operatie werkt ook op databases . In een loopje: oude waarde uitlezen, nieuwe waarde (oude_waarde + 1) wegschrijven dmv WHERE waarde=oude_waarde, en dat herhalen totdat affected_rows > 0

.edit: niet dat ik dit nou zo'n fantastische methode voor dit probleem vind overigens, maar een "disaster waiting to happen" is wat kort door de bocht

[ Voor 17% gewijzigd door .oisyn op 16-06-2010 14:44 ]

[Snake]

.oisyn schreef op woensdag 16 juni 2010 @ 14:40:
[...]

Nonsense, een test-and-set operatie werkt ook op databases . In een loopje: oude waarde uitlezen, nieuwe waarde (oude_waarde + 1) wegschrijven dmv WHERE waarde=oude_waarde, en dat herhalen totdat affected_rows > 0

.edit: niet dat ik dit nou zo'n fantastische methode voor dit probleem vind overigens, maar een "disaster waiting to happen" is wat kort door de bocht

Dan moet je wel de gehele tabel locken he. Anders insert misschien iemand terwijl jij aan denkt 'ik heb een value die niet bestaat!'

[.oisyn]

Nee hoor, je hoeft niets te locken. Wel moeten individuele database operaties zelf wel atomair zijn, maar als dat al niet het geval is dan voldoet je db sowieso niet voor multi-user access.

In pseudocode:

code:

do
{
    old_id = [SELECT id FROM idtable WHERE name='mijntabel'];
    insert_id = old_id + 1;
    affected_rows = [UPDATE idtable SET id=insert_id WHERE id=old_id AND name='mijntabel']
} while(affected_rows == 0);

Voorbeeld usecase: in de database staat een id van 9. Die lees je uit, verhoog je met 1 naar 10, en die schrijf je terug als er nog een 9 staat. Als er iemand anders tussendoor komt die ook een 9 uitleest maar een 10 schrijft voordat jij een 10 schrijft, dan is er geen kolom meer waar eerst een 9 stond en dus update je niets. Het aantal aangepaste rijen is dan 0, en dus begin je van voor af aan. Dit is basis lockless programming, waar een test-and-set perfect voor werkt. Een mutex is op een vergelijkbare manier geïmplementeerd: schrijf een 1 als er eerst een 0 stond. Stond er een 1, dan moet je wachten want dan heeft iemand anders de lock. Stond er een 0 dan is de write succesvol geweest en staat er nu een 1 en heb jij de lock.

[ Voor 86% gewijzigd door .oisyn op 16-06-2010 15:12 ]

[ieperlingetje]

Het is een single user omgeving, dus niet echt veel last van concurrency.

[RobIII]

.oisyn schreef op woensdag 16 juni 2010 @ 14:40:
.edit: niet dat ik dit nou zo'n fantastische methode voor dit probleem vind overigens, maar een "disaster waiting to happen" is wat kort door de bocht

Goed; het kan wel inderdaad maar we hebben het hier over Access he? Vandaar dat ik wat chargeerde. Ik zou toch eerder gewoon vertrouwen op de auto-increment ID en @@identity

[ Voor 9% gewijzigd door RobIII op 16-06-2010 15:10 ]

[BvDorp]

Zeker in single-use omgeving is het makkelijker om te werken met XML, of met ADO.NET zonder SQL code. Gewoon een beetje tableadapters updaten en fillen en het werkt als een trein. Loop eens wat voorbeelden door.

XML werkt ook onwijs lekker. Je kunt een mooie DataStorage class schrijven, en die hele class in één keer wegschrijven naar een .XML file. Hiermee kun je ongelooflijk makkelijk met strongly typed objecten in je programma werken.

[RobIII]

BvDorp schreef op woensdag 16 juni 2010 @ 23:44:
Zeker in single-use omgeving is het makkelijker om te werken met XML, of met ADO.NET zonder SQL code.
...
XML werkt ook onwijs lekker. Je kunt een mooie DataStorage class schrijven, en die hele class in één keer wegschrijven naar een .XML file.

Ja want een eigen-geschreven "XMLDB"-implementatie biedt alle zaken als transacties, indexen, efficiënte opslag, security, data integrity, triggers etc in optima forma

Het is dat je met LINQ nog wat kunt weg-abstraheren maar waarom je met XML komt aankakken is mij werkelijk een raadsel. En gebruik dan gewoon een bestaande XML DB en ga er niet zelf 1 zitten schrijven.

Het is misschien een flinke lap om te lezen, maar lees dit eens _{(wat weer verwijst naar punt 2 hier)}; daarin wordt kort aangestipt waarom XML als DB (ook) niet echt een slim idee is (qua performance). _{Sowieso is 't een fantastisch artikel om eens gewoon te lezen.}

Als het gaat over 5 records, bij wijze van, valt het nog te verdedigen misschien, maar weet jij dat van de TS? Zodra je het hebt over wat meer records (honderden, duizenden en meer) en bijv. relationele data etc. dan ga je al gauw op je bek. Eigenlijk is voor het opslaan van zélfs een contactlijstje, dvd-collectie of whatever XML niet echt te verdedigen als je bedenkt dat er zat gratis, lightweight DBMS-en zijn. XML is (o.a.) bedoeld voor het uitwisselen van data tussen verschillende systemen/platformen en is nou niet bepaald efficiënt of handig als database.

BvDorp schreef op woensdag 16 juni 2010 @ 23:44:
Hiermee kun je ongelooflijk makkelijk met strongly typed objecten in je programma werken.

En dat gaat met een database niet Wil je het jezelf makkelijk(er) maken, kijk dan eens naar ORM software als LLBLGen, NHibernate, ActiveRecord etc. of gewoon LINQ to SQL

[ Voor 83% gewijzigd door RobIII op 17-06-2010 02:59 ]