SQL Package

[Fuerchau]

Das ist ja genau das was ich meine.
Die SQL's können nur wiederverwendet werden, wenn sie IDENTISCH sind. Somit gilt jeder Befehl als neuer SQL und ODP's gibt es nicht.

Wenn ich mir den Befehl so betrachte, wird ja genau eine bestimmte Sicht der Daten verlangt, also ähnlich einem CREATE VIEW die ich dann mittels SELECT * FROM MYVIEW abfrage. Es wird also immer erst eine neue View (eben temporär) verlangt.

Daher erklärt sich auch die Performance, da der SQL generell neu analysiert werden muss, ein SQLPKG also nichts bringt. (Wenn man SQLPKG nicht definiert, wird automatisch eins in QGPL generiert.)

Aber auch auf der Clientseite muss ich mit Parametern arbeiten können !!!!

Wenn ich mit ADO arbeite, so erstelle ich ein Connection-Object an das ich dann Command-Objekte hänge.
Den SQL definiere ich an den richtigen Stellen mit "?" und kann dann jederzeit mit "OpenRecodset" und den Parametern im Array (oder in einer Schleife gefüllt) das Command ausführen.

[Asti]

Den SQL definiere ich an den richtigen Stellen mit "?" und kann dann jederzeit mit "OpenRecodset" und den Parametern im Array (oder in einer Schleife gefüllt) das Command ausführen.

Kann ich an einen Parameter ein Array hängen? Arbeite bei INSERT nur noch mit ado command und wüsste gerne, ob man das noch beschleunigen kann, indem man nicht jede Zeile einzeln "abschickt" sondern ein array an jeden Parameter anhängt und dann einen ganzen Block überträgt. Habe das mit ODBC BLOCK INSERT probiert, funktioniert auch, möchte das aber lieber über ado realisieren. Gibt es eine Art BLOCK INSERT für ado (VB6)?

Gruß Andreas

[Fuerchau]

Nun, das geht nur über ein Recordset, dass vorher per "SELECT ..." angelegt wurde, wichtig ist hierbei die Verwendung eine CLientCursers.

Per .AddNew-Methode können dann neue Sätze erst mal lokal hinzugefügt werden, vorhandene Sätze können direkt per ".Fields("Name")" bzw "!Name" geändert werden.

Zum Schluß ist dann die Methode .UpdateBatch aufzurufen, die nun alle Änderungen in die Zieltabelle überträgt.

Über den Filter ".adFilterPendingRecords" bzw. ".AdFilterConflictingRecords" können die nicht übertragenen bzw. fehlerhaften Sätze ausgefiltert werden.

UpdateBatch hat ggf. in Mehrbenutzerumgebeungen den Nachteil, dass Änderungen/Neuanlagen nicht sofort für alle verfügbar sind und Konflikte schwerer erkennbar werden.

Auch die Anzahl der Operationen (Speicherbedarf) ist da begrenzt.

Es funktioniert also auch folgendes:

Set MyRcd = MyConnect.Execute("Select * from MyTable where Key1=''"

' Erzwingen eines leeren Recordsets

for x=1 to 1000
MyRcd.AddNew
MyRcd!F1 = newval

if x mod 100 = 0 then
MyRcd.UpdateBatch
MyRcd.Requery
endif

next

' Update alle 100 Sätze
' Requery gibt wieder ein leeres Recordset