LOCKTABLE

lyot

Hallo,

Ik heb gelezen dat vooraleer een repaet lus te coderen men beter eerst het volgende eens bekijkt.

1) kleine recordset <500 records

2) grote recordset >500 records

3) aanpassingen in te doorlopen recordset

Ik heb het voornamelijk over geval (1), daar raadt MS aan om op de volgende manier te werk te gaan.

lrecBin.RESET;
lrecBin.SETRANGE("Location Code",pcodLocation);
lrecBin.SETRANGE("Zone Code",pcodZone);
lrecBin.LOCKTABLE;

IF lrecBin.FINDSET THEN
  REPEAT
    //code
  UNTIL lrecBin.NEXT=0;

Mijn vraag is nu of de LOCKTABLE functie enkel de gefilterde recordset zal locken of toch de ganse tabel Bin.
Ik hoop ten zeerste dat het het eerste is... :?

PS:db is op sql

Marije_Brummel

Alleen de recordset. Tenminste, als je de juiste SETCURRENTKEY toevoegd en er een passende SQL index is.

LOCKTABLE is een erfenis uit de Native database en zou beter LOCKRECORDSET kunnen heten teneinde minder spraakverwarring te veroorzaken. Helaas.

Let op dat Navision een isolation level op transactieniveau zet. De volgende actie op deze tabel is altijd met UPDLOCK of je dat nu leuk vindt of niet.

lyot

Mark Brummel wrote:

Alleen de recordset. Tenminste, als je de juiste SETCURRENTKEY toevoegd en er een passende SQL index is..

Wilt dat dan zeggen dat ik in bovenstaande code dan expliciet de volgende regel moet toevoegen?

lrecBin.SETCURRENTKEY("Location Code","Zone Code",Code)

Bepaalt SQL niet reeds de optimale key voor mijn query?

Mark Brummel wrote:

Let op dat Navision een isolation level op transactieniveau zet.
De volgende actie op deze tabel is altijd met UPDLOCK of je dat nu leuk vindt of niet.

Dus als mijn bovenstaande code is uitgevoerd valt die UPDLOCK weg?

Marije_Brummel

De Query optimiser zal inderdaad de beste index voor de job bepalen. Alleen als je geen SETCURRENTKEY toevoegd zal de ORDER BY gewoon de clustered index sortering zijn. De Query Optimiser zal dan eerder geneigd zijn om een kleine table te scannen omdat 'm geen sortering hoeft te doen.

SETCURRENTKEY is altijd beter in dit soort gevallen.

Als er geen SQL Index voor de job is zal SQL de next best zoeken of alsnog een index scan doen en te tabel op slot gooien.

In jouw voorbeeld zal de query iets zijn van SELECT TOP 500 FROM BLABLA WITH(UPDLOCK) WHERE BLABLA

De volgende keer als je binnen dezelfde transactie (Dus zonder COMMIT) een FINDSET(FALSE) doet zal de driver toch een UPDLOCK genereren omdat de oude Native database dat ook deed.

Ik weet het, het is jammer maar don't shoot the messenger...

lyot

Mark Brummel wrote:

De volgende keer als je binnen dezelfde transactie (Dus zonder COMMIT) een FINDSET(FALSE) doet zal de driver toch een UPDLOCK genereren omdat de oude Native database dat ook deed.

Dat er niemand een update/modify kan uitvoeren op die recordset tijdens mijn transactie is de bedeoeling.
Maar begrijp ik nu correct dat niemand anders deze kan lezen tijdens mijn transactie?? :shock:

Marije_Brummel

Zucht...

Je begrijpt me helemaal verkeerd. Dit is zwaar complexe theorie en normaal geef ik hier 2 daagse workshops over.

Het standaard isolation level voor lezen is READUNCOMMITTED dus iedereen kan gewoon lezen tijdens jou transactie.

lyot

Mark Brummel wrote:

Het standaard isolation level voor lezen is READUNCOMMITTED dus iedereen kan gewoon lezen tijdens jou transactie.

Oké, het geeft enkel een probleem als ik tijdens diezelfde transactie (na de locktable) een findset wil uitvoeren.
Gelukkig is dit in mijn geval (nog) niet zo... [-o<

Alvast bedankt voor de hulp! =D>

Marije_Brummel

Graag gedaan.

Binnenkort mag ik spreken op een belgische MSDN avond. Misschien zie ik je daar.

lyot

Bedankt voor de info!
Ik zal er zijn.