ADO und Informix

[Helmut Schumacher]

Hallo <br>
kann man über ADO auf Informix zugreifen.<br>

Helmut

[Andreas Kosch]

Hallo,

ja - wenn man entweder <br>
a) einen <i>OLE DB Provider</i> für diese Informix-Datenbank, oder <br>
b) einen <i>ODBC-Treiber</i> (ab der Version 3.x) <br>
zur Verfügung hat

[Helmut Schumacher]

Hallo Herr Kosch<br>

Bei meiner Anwendung ist eine Parallelverarbeitung aus zeitlichen Gründen unbedingt erforderlich. Daher wird wohl ein ODBC-Treiber nicht in Frage kommen. Ein OLE-DB Treiber währe schon das Richtige aber gibt es ein OLE-DB Treiber für INFORMIX ? Das ist eigendlich meine Frage.

Helmu

[Andreas Kosch]

Hallo,

ein ODBC-Treiber ab der Version 3 muss threadfest sein, so dass er innerhalb des IIS und MTS/COM+ verwendet werden kann. Und in diesen Umgebungen wird immer mit mehreren Arbeitsthreads hantiert (IIS= 10 Threads pro CPU; COM+ = 100 Threads pro CPU).

Mir ist nicht bekannt, ob es einen OLE DB-Provider für Informix gibt, wobei es in diesem Fall auch auf die exakte Versionsnummer der Informix-Datenbank ankommt. Wenn Informix selbst keinen Treiber bereitstellt, würde ich die Finger von dieser Datenbank lassen

[Helmut Schumacher]

Hi<br>
Zwischenzeitlich habe ich von Informix einen OLE DB Provider!<br>
Leider kann ich bisher, gegenüber der BDE, noch keinen performanz Gewinn feststellen? Auf welche Einstellungen könnte man besonnders achten, um ein maximales an Performanz zu bekommen. Ich möchte nur Datensätze in der Datenbank neu anlegen. Also nicht irgend wie rauf und runter Scollen.
Helmu

[Andreas Kosch]

Hallo,

über welchen Weg werden denn die Daten in die Informix-Datenbank eingefügt? Wenn <b>TADOCommand</b> (ADO Express) oder das native <b>Command</b>-Objekt in ADO verwendet wird, erreicht man bessere Ergebnisse als mit der BDE.

Für das Updaten von 100 Datensätze in einer SQL Server 2000-Datenbank habe ich die folgenden Zahlen ermittelt: <br>
a) TADODataSet mit BatchOptimistic: 451 Millisekunden <br>
b) TADODataSet: 280 Millisekunden <br>
c) TADOCommand (UPDATE-SQL): 220 Millisekunden <br>
d) Command-Objekt (UPDATE-SQL): 170 Millisekunden

Wenn es auf maximale Performance ankommt, würde ich auf ADO Express verzichten und die Datensätze über eine Stored Procedure der Datenbank anlegen. Das folgende Beispiel demonstriert den schnellsten INSERT-Weg:
<pre>
procedure TForm1.TestADO_Native;
var
aConnection : _Connection;
aCommand : _Command;
aParam : _Parameter;
vEINTRAG1 : OleVariant;
vEINTRAG2 : OleVariant;
vDATUM : OleVariant;
vBETRAG : OleVariant;
vRows : OleVariant;
i : Integer;
s : String;
c : Currency;
begin
aConnection := CoConnection.Create;
aConnection.Open(ADOConnection1.ConnectionString, '', '', -1);
aCommand := CoCommand.Create;
aCommand.Set_ActiveConnection(aConnection);
aCommand.CommandType := adCmdStoredProc;
aCommand.Set_CommandText('insert_vergleich;1');
aParam := aCommand.CreateParameter('@EINTRAG1', adVarChar, adParamInput, 50, vEINTRAG1);
aCommand.Parameters.Append(aParam);
aParam := aCommand.CreateParameter('@EINTRAG2', adChar, adParamInput, 10, vEINTRAG2);
aCommand.Parameters.Append(aParam);
aParam := aCommand.CreateParameter('@DATUM', adDBTimeStamp, adParamInput, 8, vDATUM);
aCommand.Parameters.Append(aParam);
aParam := aCommand.CreateParameter('@BETRAG', adCurrency, adParamInput, 8, vBETRAG);
aCommand.Parameters.Append(aParam);
aCommand.Prepared := True;
if CheckBoxTrans.Checked then
aConnection.BeginTrans;
FStartTicks := GetTickCount;
for i := 1 to cLOOP_COUNT do
begin
s := IntToStr(i);
c := 2.12 * i;
vEINTRAG1 := s + ' Testeintrag' + s;
vEINTRAG2 := s + ' XYZ';
vDATUM := Now;
vBETRAG := c;
aCommand.Execute(vRows, VarArrayOf([vEINTRAG1, vEINTRAG2, vDATUM, vBETRAG]), adExecuteNoRecords);
if i mod 100 = 0
then ProgressBar1.StepIt;
end;
if CheckBoxTrans.Checked then
aConnection.CommitTrans;
FStopTicks := GetTickCount;
s := Format('ADO Connection/Command : %d Ticks', [FStopTicks - FStartTicks]);
MemoLog.Lines.Add(s);
ShowMessage(s);
ProgressBar1.Position := 0;
end;
</pre>
Wenn es nicht auf die letzte Millisekunde ankommt, ist die Aufgabe mit <b>TADOStoredProc</b> einfacher:
<pre>
procedure TForm1.TestADO_TADOStoredProc;
var
i : Integer;
s : String;
c : Currency;
begin
ADOConnection1.Connected := True;
ADOStoredProc1.Prepared := True;
if CheckBoxTrans.Checked then
ADOConnection1.BeginTrans;
FStartTicks := GetTickCount;
for i := 1 to cLOOP_COUNT do
begin
s := IntToStr(i);
c := 2.12 * i;
ADOStoredProc1.Parameters[1].Value := s + ' Testeintrag' + s;
ADOStoredProc1.Parameters[2].Value := s + ' XYZ';
ADOStoredProc1.Parameters[3].Value := Now;
ADOStoredProc1.Parameters[4].Value := c;
ADOStoredProc1.ExecProc;
if i mod 100 = 0
then ProgressBar1.StepIt;
end;
if CheckBoxTrans.Checked then
ADOConnection1.CommitTrans;
FStopTicks := GetTickCount;
s := Format('ADO Express (TADOStoredProc): %d Ticks',[FStopTicks - FStartTicks]);
MemoLog.Lines.Add(s);
DataSourceVERGLEICH.DataSet := ADOTable1;
ADOTable1.Active := True;
ShowMessage(s);
ADOTable1.Active := False;
ADOConnection1.Connected := False;
ProgressBar1.Position := 0;
end;
</pre>
&#10

[Helmut Schumacher]

Hallo <br>
Ist es eigendlich auch möglich, wenn man grosse Datenmengen von einer, wie in meinem Fall, Oracle-DB zu einer Informix-DB transverrieren soll und beide Datenbanksysteme mit einem OLE-DB Privider erreichbar sind, das Dataset einfach gleich zu setzen?
<br>
Ich meine so etwas wie <br>
<b>ADODataSet_Informix.Recordset := ADODataSet_Oracle.Recordset oder
ADODataSet_Informix.Clone(ADODataSet_Oracle, ltUnspecified) </b>

und anschliessend mit ADODataSet_Informix.UpdateBatch???? oder
so etwas wie ADODataSet_Informix.ApplyUpdate <BR>
die Datensätze in der anderen Datenbank hinzufühgen?

Helmut

und anschliessend mit ADODataSet_Informix.
<br>
Helmu

[Helmut Schumacher]

da ist ein kleiner Schreibfehler.<br>
Und was ich noch fragen wolte, wenn soetwas geht dann wie??
<br>
Helmu

[Andreas Kosch]

Hallo,

beim <i>Microsoft SQL Server 7/2000</i> wird extra das Tool <b>DTS-Assistent</b> mit ausgliefert, mit dem man Daten aus beliebigen ODBC- und OLE DB-Quellen in die SQL-Datenbank laden kann.

Im eigenen Programm wird man nicht umhin kommen, jeden einzelnen Datensatz über INSERT in die Zieltabelle zu schreiben. Denn in den meisten Fällen sind sowie irgendwelche Anpassungen/Prüfungen notwendig, die bei dieser Gelegenheit gleich mit erledigt werden.

Man kann zwar versuchen, die mit <b>ltBatchOptimistic</b> aus der ORACLE-Datenbank angeforderte Datenmenge der SELECT-Abfrage als lokale Datei zu speichern, die TADOConnection-Instanz dann auf die Informix-Datenbank umzuhängen, die lokale Datei über die TADODataSet-Instanz wieder zu öffnen und dann einen <b>UpdateBatch</b>-Aufruf auszulösen. Ob das aber auch in der Praxis funktioniert, kann ich nicht sagen

[Helmut Schumacher]

Hallo, <br>
in meiner Sache bin ich leider noch nicht weiter gekommen. Das Problem besteht darin, das die Daten aus einer Oracle-DB mit ADO sehr schnell bereit stehen. 1 Mill Datensätze in 30 Min. Nun sollen diese Daten in eine Informix-DB. Mit der BDE (Schleife Query u. SQLExec) dauert dieser Vorgang dann sechs Stunden. Dies ist erheblich zu lang. Ist es Möglich, dass TBatchMove schneller ist?? Wenn ich auf dem localen System eine temp-Table ala Paradox aufbaue?
<br>
Helmu

[Andreas Kosch]

Hallo,

nur 2 Fragen: <br>
1. Wurden die Indizes in der Informix-DB vorher deaktiviert? <br>
2. Wurde nach jeweils ca. 500 Datensätzen ein COMMIT ausgelöst

[Helmut Schumacher]

Hallo<br>
die Indexe wurden zuvor gelöscht.<br>
ein COMMIT wurde nicht nach 500 Datensätze ausgelöst, sondern erst ganz zum Ende der Tabelle. Es wird aber ein exclosives LOCK auf die Tabelle gesetzt.<br>
Helmu

[Andreas Kosch]

Hallo,

ich kenne Informix nur vom Hörensagen, aber es wäre einen Versuch wert, die Transaktionen in "kleinere Häppchen" aufzuteilen. Eventuell schreibt er trotz Exlusivmodus seine Logs intern weiter, um einen Rollback durchführen zu können

[Stefan Heitsiek]

Hallo zusammen,
leider weiss ich nicht auf welchen BS die DBs laufen, iss aber auch eigentlich egal. Bei einer solchen Datenmenge und wenn es sich um einen einmaligen Vorgang handelt, würde ich immer die DB-Bordwerkzeuge benutzen, weil sonst einfach zuviel Software dazwischen hängt. D.h. ich würde die Oracle-Tabs in Ascii-Files entladen und auf Informix-Seite entweder mit "load from .... insert into ..." oder mit dem Informix High Performance Loader die Daten laden. Ausserdem würde ich auf Informix Seite vor dem Laden die DB auf "No logging" setzen. Damit erspart man sich die Commit-Problematik.

Stefa

[Helmut Schumacher]

Hi, <br>
danke für den Hinweis, zur Zeit habe ich eine Lösung. Die Daten werden von der Oracle-DB (Windows NT) clientseitig in eine Datei aufbereitet. Dies ist dank ADO sehr schnell. Anschliessend wird die Datei per FTP zur Informix-DB (Unix) gesendet und dort über das Informix-Tool "DBLoad" in eine Tabelle geladen. Dieses Verfahren ist von der Perfomanc brauchbar. Eine kleine Besonderheit ist, DBLoad wird über eine StorProc nach dem FTP gestartet. Damit ist die Sache rund.<br>
Helmu