[sql2000] hoe werkt MS SQL Server in mulit-user omgeving

[Verwijderd]

Ik ben bezig om een ontwerp te maken van een multi-user applicatie (>50 gebruikers) in VB.NET met als database platform MS SQL Server 2000. De organisatie wenst dat alle SQL statements uitgevoerd worden door stored procedures en niet door ADO.

Nu mijn vragen:

Wanneer in het theoretische geval twee of meer gebruikers gelijktijdig dezelfde stored procedure opstarten hoe gaat SQL Server hier mee om? Maakt SQL server gebruik van een bepaalde transactiepool oid? De reden dat ik dit vraag is het al dan niet gaan gebruiken van de @@identity om de laatst toegevoede id op te halen.

Het zou kunnen voorkomen dat meerdere gebruikers dezelfde gegevens uit een record gaan wijzigen, vb: gebruiker a haalt een detailvester op en gaat naar het toilet, gebruiker b haalt dezelfde gegevens op tijdens de plaspauze en voert een wijziging door, a komt terug en voert ook een wijziging door. Hierdoor zijn de door b doorgevoerde wijzigingen verloren gegaan. Biedt SQL Server iets waardoor dit voorkomen kan worden of dien je dit zelf op te lossen door bv "een datum/tijd laatste mutatie" bij te houden en die te controleren voordat je de wijziging door gaat voeren?

[P_de_B]

Je zult je wat moeten inlezen over "Locking" en "Transaction Isolation". In books online is daar veel info over te vinden, veel meer dan ik je zo in een reply kan geven.

@@Identity geeft wel de goede ID terug, het is niet zo dat je een ID van een andere gebruiker krijgt. Als je ook triggers in je applicatie gebruikt kun je geen @@Identity gebruiken, maar moet je SCOPE_IDENTITY() gebruiken.


Bottom line: SQL Server heeft verschillende opties om met jouw voorbeeld om te gaan, je moet zelf bepalen welke optie je kiest.


Het verhaalte over ADO vs. Stored Procedures begrijp ik niet zo goed, je gebruikt immers ADO om een Stored Proc aan te roepen.

Heb je je ook afgevraagd waarom ze alles via stored procs willen? In veel gevallen is de performance niet slechter dan die van (geparameteriseerde) dynamische queries.

[whoami]

Je zult toch ADO.NET gebruiken om die SP's aan te spreken hoor. Waarschijnlijk bedoel je dat je geen gebruik mag maken van embedded SQL statements.

De @@identity variable scope is beperkt tot de huidige sessie. Dat wil dus zeggen dat als jij SELECT @@identity doet, je het ID krijgt van het laatste record dat jij geinsert hebt.
Je moet wel oppassen, want hier schuilt een addertje onder het gras:
Als je een tabel A hebt, en je hebt een TRIGGER op die tabel A die een record insert in een tabel B (beide tabellen hebben een column met autonummering); en je insert een record in tabel A en je vraagt de @@identity op, dan verwacht je waarschijnlijk dat je het ID krijgt van het record in tabel A, je krijgt echter het ID v/h record van tabel B.
Je kan ook eens kijken naar de functies scope_identity() en IDENT_CURRENT().

Als je trouwens gebruik gaat gaan maken van SP's om records te inserten, dan verklein je de kans toch al dat je verkeerde ID's gaat gaan terugkrijgen.
Je gaat dan nl. een SP maken om een record te inserten en die SP zal er dan als volgt uit zien:

code:

CREATE PROCEDURE InsertRecord ( @p_Blaat VARCHAR(25), 
@p_Blaat2 VARCHAR(25), 
@p_Id INTEGER OUTPUT)
AS
BEGIN
   INSERT INTO tabel
   (veld1, veld2) 
   VALUES
   (@p_Blaat, @p_Blaat2)

   SELECT @p_Id = scope_identity() FROM tabel
END

[Verwijderd]

P_de_B schreef op 16 januari 2004 @ 08:46:
Je zult je wat moeten inlezen over "Locking" en "Transaction Isolation". In books online is daar veel info over te vinden, veel meer dan ik je zo in een reply kan geven.

Gevonden in de books online en neem ze nu door.

P_de_B schreef op 16 januari 2004 @ 08:46:
Het verhaalte over ADO vs. Stored Procedures begrijp ik niet zo goed, je gebruikt immers ADO om een Stored Proc aan te roepen.

Heb je je ook afgevraagd waarom ze alles via stored procs willen? In veel gevallen is de performance niet slechter dan die van (geparameteriseerde) dynamische queries.

whoami schreef op 16 januari 2004 @ 08:46:
Je zult toch ADO.NET gebruiken om die SP's aan te spreken hoor. Waarschijnlijk bedoel je dat je geen gebruik mag maken van embedded SQL statements.

oeps... niet helemaal correct verwoord, echter whoami slaat de spijker op z'n kop

Beiden bedankt voor de uitleg over @@identity, scope_identity() en IDENT_CURRENT(). Ik heb de info in de books online bekeken en dit verduidelijkt veel.

Als ik het goed begrijp moet ik wel het tweede voorbeeld zelf oplossen, de locks vinden pas plaats bij het uitvoeren van de sp die de update van de gegevens verwerkt, of mis ik iets?

[whoami]

Je hebt verschillende manieren van locking:
- optimistic locking
- pessimistic locking

In short:
Bij optimistic locking komt het erop neer dat er vanuit gegaan wordt dat de kans klein is dat 2 users hetzelfde record tegelijk willen wijzigen, en is meestal de te preferreren manier.

Bij pessimistic locking ga je een een lock op het record plaatsen vanaf het moment dat het geopend wordt. Anderen kunnen dat record dan wel nog bekijken, maar niet wijzigen, tot wanneer de lock opgeheven is.

[P_de_B]

Verwijderd schreef op 16 januari 2004 @ 09:05:
[...]

Als ik het goed begrijp moet ik wel het tweede voorbeeld zelf oplossen, de locks vinden pas plaats bij het uitvoeren van de sp die de update van de gegevens verwerkt, of mis ik iets?

Ligt eraan wat voor locking gedrag je wilt 'pessimistic' of 'optimistic'. Ook hierover is veel te vinden in Books online. Je zult zelf op basis van hoe belangrijk de gegevens zijn een keuze moeten maken.

[Verwijderd]

ok, genoeg voer om de dag mee door te komen. dank aan u beiden