Probleme mit Post unter MS SQL-Server

[Friedel Liberti]

Probleme mit Post in SQL-Server.

Die Verwendung von <Table>.Post bei einer groesseren Anzahl
geoeffneter Tabellen fuehrt zm kompletten Stillstand der Clientanwendung.
Meiner Vermutung nach wird ein komplettes commit mit zurueckschereiben aller logs veranlasst.

Friedel

[Bernhard Geyer]

Hier wäre folgendes Angaben noch Interessant:

Welche SQL-Server-Version?<br>
Welcher Service-Pack?<br>
Welche Zugriffsweg von Client (ODBC, ADO, ...)?<br>
Welche Client-Treiber-Version (ODBC, SQL-Server)?<br&gt

[Andreas Kosch]

Hallo,

ich vermute einmal, das es sich hier um das sogenannte "Fetch All"-Problem handelt. Wenn beim AutoCommit nach dem Post die Transaktion abgeschlossen wurde, versucht die BDE/VCL alle Datensätze aller Ergebnismengen, die bisher noch nicht zum Client transportiert wurden, zu "retten", indem diese zum Client geladen werden.

Stellt man die Daten einer Tabelle in einem DBGrid dar, lädt die VCL nur die sichtbaren Datensätze zum Client, und lässt alle anderem auf dem Server. Wenn die Transaktion beendet wird, geht die Ergebnismenge auf dem Server verloren, so das die VCL alle Datensätze vorher abholt. Dies führt zum scheinbaren Stillstand der Anwendung, in Wirklichkeit ist der Rechner und das Netzwerk schwer am schuften ;-)

Es gibt ein Universalmittel das in jedem Fall das Problem beseitigt: Man muss dafür sorgen, das der Server nur kleine Ergebnismengen aufbaut, indem eine geeignete WHERE-Bedingung (alias Filter-Kriterium bei TTable) verwendet wird. Weitere Alternativen hängen stark vom verwendeten Zugriffsweg (ODBC, BDE oder ADO) bzw. von den eingesetzten Komponenten sowie vom gewählten Transaction Isolation Level ab

[Friedrich Liberti]

Hallo,

ich habe eine Lösung vorangestellten Problems gefunden. Nicht besonders glücklich aber sie untermauert die Theorie von Andreas.

Wenn das Post auf eine gleichlautende Tabelle in einer zusaetzlich angelegten Datenbank vorgenommen wird gehts flott. Der Datensatz wird nachfolgend ueber eine stored proc in die zu bearbeitende Tabelle in die richtigen Datenbank eingelesen.
Dabei wirs erstmal beim Post keine grosse Datenmenge geoffnet (siehe Andreas) und die stored proc umgeht natuerlich den client.

Dieses Problem gibt es uebrigens nur bei MSSQL-Server, nachweislich nicht bei INFORMIX.

Deshalb liegt das Problem wohl ausschliesslich bei Microsoft. Vielleicht aber auch bei Microsoft und ODBC. Ich versuchs nochmal mit ADO.

Friede

[Andreas Kosch]

Hallo,

nein, es handelt sich um ein Problem, das prinzipiell für alle Datenbanken gilt. Es ist die Aufgabe des Entwicklers, dafür zu sorgen, dass vom Client nur die wirklich unbedingt notwendigen Datenmengen angefordert werden. Anstelle eine Tabelle vollständig zu öffnen (TTable ohne Filter), sollte man die Datenmenge einschränken, damit nur eine begrenzte Anzahl von Datensätzen in der Ergebnismenge enthalten sind. Wenn dann die VCL ein FetchAll auslöst, können diese wenigen Datensätze sehr schnell nachgeladen werden, so dass es keinen Performance-Nachteil gibt.

Je nach Datenbank kann man zusätzlich auf weitere Möglichkeiten zurückgreifen. Beim Microsoft SQL Server ist auch die Syntax SELECT TOP x erlaubt, um nur die ersten x-Datensätze zu erhalten. Beim InterBase kann man die Eigenschaft MAX ROWS in der BDE-Verwaltung festlegen, die ebenfalls als "Bremse" das Laden von sehr grossen Datenmengen verhindert. Das sind aber alles nur Notlösungen, besser ist es, gleich von Anfang an über eine WHERE-Einschränkung dafür zu sorgen, das auf dem Server erst keine grosse Ergebnismenge existiert