BDE/MSSQL Tabelle gelockt bei SELECT

[Sunny]

Hallo zusammen,

ich bin gerade über ein Problem gestolpert.

Wenn ich über BDE - TQuery einen einfachen SELECT auf
eine Tabelle ( MSSQL ) mit einigen 100 Einträgen ausführe,
wird offensichtlich nur ein Teil der Tabelle gelesen.
( laut SQL-Monitor )

Zugriff mit readOnly und requestlive = FALSE

Soweit noch OK.

NUR! die Tabelle ist nun gelocked.

Sobald ich ans Ende der Tabelle springe ( mit last ) oder
den recordcount lese wird die Sperre aufgehoben.

Kann man dieses Locking irgendwie verhindern ?

[Phoenix]

Er ja. Guck mach nach dem Stichwort dirty reads.

Aber wundere Dich dann nicht, wenn Du auf einmal einen halb geänderten Datensatz im Resultset hast. Die Locks setzt die Datenbank ja nicht umsonst ;-)

[Sunny]

Hallo Phoenix,

das locking ist ja während des Lesens von den n ersten Zeilen OK.
Aber warum muß ( die BDE ? ) bis zum Weiterlesen die Tabelle
gelockt halten ?

Ich fürchte das Problem liegt irgendwo in der BDE in Zusammenhang
mit MSSQL 7.0

[Bernhard Geyer]

Warum wechselst Du nicht auf ADO(-Express)? Ist für M$-SQL eh die bessere (weil problemlosere) Alternative. Und dort kannst Du auch sehr einfach den Sperr-Typ einstellen.

[Sunny]

ADO ist sicher eine Alternative.

Trotzdem würde mich interessieren, ob dieses Verhalten
grundsätzlich vorhanden ist, oder ob es noch eine Möglichkeit
das Locking zu unterbinden.

Ich hoffe immer noch, daß ich irgendwo etwas übersehen habe.

[Robert_G]

Record locking beim Lesen ist doch totaler Käse!
Frag's Pferd warum (oder ob) das bei der BDE eine Standardeinstellung ist. Beim Auslesen bekommt die Abfrage die aktuellsten konsistenten Daten (wenn also für ein paar Einträge noch Transaktionen ausstehen, sieht man die Version dieser Einträge vor der Transaktion).
Du würdest doch sonst alles lahm legen, da ja ständig irgendein Client Daten abfragt.
Eingeber 1 lädt eine Seite, Eingeber 2 will in die gleiche Tabelle zu einem anderem Patienten schreiben -> soll der etwa immer einen Augenblick warten, nur weil irgend jemand gerade die Daten abfragt???

Zitat:

Aber wundere Dich dann nicht, wenn Du auf einmal einen halb geänderten Datensatz im Resultset hast. Die Locks setzt die Datenbank ja nicht umsonst ;)

Das verstehe ich nicht ganz...
Ein Datensatz kann doch nur halb geändert sein, wenn der Entwickler so unfähig ist und Änderungen pro Feld durchführt.
Zusammegehörenden einträge werden gemeinsam in einer Transaktion gespeichert (zum Bleistift eine Seite in der Eingabemaske).
Die Abfrage kann dann einfach keine inkosistenten Daten bekommen.

Vielleicht bin ich ja zu blöd ( :roll: ), aber ich kann da absolut gar keinen Sinn erkennen, warum ein SELECT-Statement die Tabelle sperren sollte.

Edit: 5 mio. Tippfehler...

[Smokey]

Das Sperren beim Lesen hat durchaus seine Berechtigung, da es zu mehreren fehlern kommen kann.
1. unrepeatable Read
2. falsche Summenbildung
3. Dirty Read

wollte nun gerade anfangen dir einige beispiele dazu zu nennen, was alles schiefgehen kann, wenn du keine Lesesperre setzt, aber meine Kollegen schreien nach mittagspause und essen. Und das würde alles etwas länger dauern :stupid:

Aber kannst ja mal nach den Sachen suchen, man findet da Massen an Seiten zu.
Das Problem mit dem Typ A liest Daten von Patient A, dadurch kann Typ B nicht Patient B ändern ist nur ein sehr geringes Problem.
Zum einen dauert ein reiner Lesezugriff nur minmal lange
Zum anderen werden bei guten DB-Systemen nicht ganze Tabellen gesperrt

Naja Transactionen sind nen riesen Thema...aber soviel kann gesagt werden : Lesesperren sind wahrlich nicht unnütz

[Robert_G]

Zitat:

Schreibsperren sind wahrlich nicht unnütz

Gegen das Sperren beim Schreiben sage ich ja auch nix ;)

[Smokey]

ups, in der Eile Richtung Pool/Essen zu kommen habsch tatsächlich Schreibsperre geschrieben...sofort mal ändern :wink: