ADO, MS SQL, Autoinc , Connection Properties-wie gehts richtig?

[Peter A. Smolik]

Hallo,

Gibt es eine allgemein gültige Regel im Umgang mit der ADO und MS SQL 7 wie man folgende Struktur aufbaut.

Dataset1: Kopfdatensatz (ID1:Autoinc)
Dataset2: Positionen (ID1,ID2:AutoInc)
Dataset3: PosStkl (ID1,ID2,ID3:Autoinc)

Also ich Lege den Kopfdatensatz an. Nur wenn ich CursorType auf clStatic setze sehe ich auch nach dem Post die ID1)
Danach wird ein Angebot dazu gesucht und die Positionen dazu importiert.

Also wieder ein Append aber diesmal auf Dataset2 (ID2=AUTOINC) Hier funktioniert ja noch alles.

Nun wird nach dem Post ins Dataset2 nachgeschaut ob es eine Stückliste dazu gibt. Da fangen dann die SChwierigkeiten an:
Ich sehe nach dem Post von Dataset2 den Datensatz offensichtlich nicht da ich ja mit den Daten daraus die Stückliste suchen möchte aber alle Felder sind leer. Erst wenn ich das Dataset2 schließe und wieder öffne hab ich Zugriff auf die Feldinhalte.

Das gleiche ist mit dem Dataset3 nach dem Post sollte geprüft werden ob der Artikel ein "Dummy" Artikel ist und eine entsprechende Suchmaske aufgemacht werden. Gleiches Problem die Felder sind alle leer. Erst nach dem Close und Open sind die Inhalte da.
Komisch ist das ich die folgenden Meldungen nur in der Entwicklungsumgebung erhalte beim Lauf des fertigen Programmes treten sie nicht auf (allerdings bekomme ich da auch keine Stücklistenartikel da ja das Dataset2 scheinbar leer ist.

Fehler Nr.1:

Der Provider konnte den Wert nicht ermitteln. Möglich Gründe der Datensatz wurde gerade erstellt, der Standardwert für das Feld steht nicht zur Verfügung oder der Benutzer hat den neuen Wert nicht gesetzt.

Fehler Nr. 2:
Das Zeilenhandle bezog sich auf eine gelöschte oder zum Löschen markierte Zeile.
(Kommt beim selben Datensatz)

Ich hab gesucht und gesucht und alle ADO Beiträge hier durchgeforstet komm aber auf keinen grünen Zweig.

Hier nocheinmal die Kurzfassung der Aufgabenstellung:

Dataset1: Kopfdatensatz
dazu gibt es ein Dataset2 das die Positionen enthält und über die ID1 mit dem Dataset1 verbunden ist.
Dann gibt es noch das Dataset3 das über die ID1 und ID2 mit dem Dataset2 verbunden ist und die Stückliste enthält. Es gibt fogende AutoInc Felder:

ID1: Dataset1
ID2: Dataset2
ID3: Dataset3

Ich denke mal es ist ein Problem der richtigen Connection Konfiguration.
Vielleicht kann mir mal jemand klar machen wie ich das richtig mache:

LG
Peter
P.S. Möchte gerne TableDirect und CursorLocation auf Server stellen (Geschwindigkeit)

[Andreas Kosch]

Hallo,

hinter dem MS SQL Server steckt eine echte SQL-Datenbank, die Mengenorientiert (nicht mehr Datensatzorientiert) und im Kontext von Transaktionen arbeitet. Die ADO-Objekte können in drei prinzipiell unterschiedlichen Betriebsarten genutzt werden: <br>
1. Server-seitiger Cursor (bei einer SQL-Datenbank die schlechteste Wahl für begründete Ausnahmefälle) <br>
2. Client-seitiger Cursor im Online-Modus<br>
3. Client-seitiger Cursor im Offline-Modus (BatchOptimistic)<br>
Bei einer SQL-Datenbank sollte man so viel wie möglich auf der Server-Seite ablegen (Stored Procedure, UDF, Trigger usw), so dass bereits dort ein Teil der Geschäftslogik abgebildet wird. Wenn zum Beispiel nach dem Anlegen eines neuen Datensatzes eine dazu gehörende Datenmenge benötigt wird, sollte für das Anlegen des Datensatzes eine Stored Procedure aufgerufen werden, die danach auch gleich die Ergebnismenge einer nachfolgenden SELECT-Anweisung liefert. In diesem Fall kann das Programm das Ergebnis direkt nutzen, ohne selbst in der eigenen Datenmenge danach zu suchen.

Um die Hintergründe für die geschilderen Problem nachvollziehbar darstellen zu können, müsse ich jetzt viel Text eintippen. Da ich dazu aber zu faul bin, belasse ich es bei einem Link: <i>http://www.software-support.biz/sus/sus_buch/psecom,id,21,nodeid,11,_language,de.html</i>

P.S: Bei einer SQL-Datenbank bremst die Einstellung clUseServer die Anwendung vollständig aus - die Performance ist in diesem Fall am Boden. Die Einstellung TableDirect ist für eine ACCESS-Datenbank gedacht (ACCESS ist keine SQL-Datenbank, sondern arbeitet Datensatzorientiert) und somit im Fall einer echten SQL-Datenbank (wie MS SQL Server) im ungünstigsten Fall kontraproduktiv

[Peter A. Smolik]

Hallo Herr Kosch,

Da sind sie genau auf meiner Linie.
Ich versuch auch soviel Logik wie möglich in die Datenbank zu bringen. (z.b. löschen mache ich nur über Stored Proc, ja selbst Berechnungen wie Rabattkonditionen, ich verwende auch sehr ausgiebig Rekursive SQL-Statements)
Leider sind da auch manchmal Grenzen die einfach in T-SQL ncith zu schaffen sind bzw. auf Grund der Portierbarkeit nicht ratsam sind.
Ich persönlich versuche immer so zu programmieren das ich MS-SQL, Oracle, Informix und wenn geht Interbase abzudecken. ich werd mal versuchen dieses importieren von Sub-Detailsätzen der Detailsätze in eine Server Prozedur auszulagern und meld mich dann ob es dann besser geht.

mfg

Pete