KM
15-01-13, 12:39
Hallo,
ich habe jetzt noch eine Menge Tests durchgeführt und dabei einige neue Erkenntnisse gewonnen.
QueryTable:
1.) Beim QueryTables.Add kann ich bekanntlich als Datenquelle ein ADODB.Recordset angeben. Wenn dieses Recordset als erste Spalte jedoch ein numerisches Feld enthält, wird die erste Spalte seltsamerweise ignoriert bzw. alle führenden numerischen Spalten werden ignoriert. Wenn das Recordset z.B. als erste Spalte ein Char-Feld enthält, funktioniert's problemlos.
2.) Wenn ich beim QueryTables.Add direkt einen ODBC-Connectionstring angebe, passt zwar das Ergebnis. Allerdings wird jedes Mal eine neue ODBC-Verbindung hergestellt. Ich weiß nicht wie Du darauf kommst, dass Connection Pooling automatisch funktioniert. Aber das stimmt nicht. Jeder Aufruf hat bei mir 1-2 Sekunden gedauert. Connection Pooling muß man laut Microsoft erst aktivieren. das habe ich auch gemacht und würde auch funktionieren (Zeitmessung dann nur noch im Hundertstelsekunden-Bereich). Allerdings scheitert dann der QueryTables.Add wegen "allgemeinem ODBC-Fehler" ohne nähere Erläuterung.
OLE DB:
Bei der OLEDB-Verbindung funktionieren durch die Einstellung des Verbindungsparameters Convert Date Time To Char=FALSE nun auch die Datumsfelder richtig. Aber wie gesagt gibt es hier die Probleme mit dem Recordset im QueryTables.Add, wenn das Recordset mit numerischen Felders beginnt. Dies kann ich aber umgehen, wenn ich die Ergebnisse des Recordsets mit CopyFromRecordset statt QueryTable in die Ziel-Tabelle einfüge. Damit funktioniert's nämlich.
Unicode-Texte:
Bei der OLEDB-Verbindung erhalte ich die Unicode-Texte korrekt zurück. Bei der ODBC-Verbindung erhalte ich sie nur, wenn ich die ODBC-Verbindung direkt beim QueryTables.Add angebe. Wenn ich erst einen Recordset damit fülle, werden die Felder als adChar interpretiert.
Ich hab mir mal die Treiber-Einstellungen angeschaut, konnte allerdings die Screenshots hier nicht hochladen. Auffällig war z.B., dass bei der ODBC-Verbindung die OLE-DB-Version auf 2.00 stand, während sie bei der OLEDB-Verbindung auf 2.50 stand. Das könnte die Ursache für die Unicode-Probleme sein. Die ODBC-Treiber-Version stand auf 3.51 und müsste dafür ausreichend sein.
Um alle meine Probleme in dieser Sache zu lösen, werde ich nun also den OLEDB-Treiber mit Recordset und zum Daten einfügen den CopyFromRecordset verwenden. Somit kann ich alle Feldtypen verarbeiten, die Daten korrekt in die Ziel-Tabelle einfügen und auch aus Performance-Gründen die Connection offen halten.
Gruß,
KM
ich habe jetzt noch eine Menge Tests durchgeführt und dabei einige neue Erkenntnisse gewonnen.
QueryTable:
1.) Beim QueryTables.Add kann ich bekanntlich als Datenquelle ein ADODB.Recordset angeben. Wenn dieses Recordset als erste Spalte jedoch ein numerisches Feld enthält, wird die erste Spalte seltsamerweise ignoriert bzw. alle führenden numerischen Spalten werden ignoriert. Wenn das Recordset z.B. als erste Spalte ein Char-Feld enthält, funktioniert's problemlos.
2.) Wenn ich beim QueryTables.Add direkt einen ODBC-Connectionstring angebe, passt zwar das Ergebnis. Allerdings wird jedes Mal eine neue ODBC-Verbindung hergestellt. Ich weiß nicht wie Du darauf kommst, dass Connection Pooling automatisch funktioniert. Aber das stimmt nicht. Jeder Aufruf hat bei mir 1-2 Sekunden gedauert. Connection Pooling muß man laut Microsoft erst aktivieren. das habe ich auch gemacht und würde auch funktionieren (Zeitmessung dann nur noch im Hundertstelsekunden-Bereich). Allerdings scheitert dann der QueryTables.Add wegen "allgemeinem ODBC-Fehler" ohne nähere Erläuterung.
OLE DB:
Bei der OLEDB-Verbindung funktionieren durch die Einstellung des Verbindungsparameters Convert Date Time To Char=FALSE nun auch die Datumsfelder richtig. Aber wie gesagt gibt es hier die Probleme mit dem Recordset im QueryTables.Add, wenn das Recordset mit numerischen Felders beginnt. Dies kann ich aber umgehen, wenn ich die Ergebnisse des Recordsets mit CopyFromRecordset statt QueryTable in die Ziel-Tabelle einfüge. Damit funktioniert's nämlich.
Unicode-Texte:
Bei der OLEDB-Verbindung erhalte ich die Unicode-Texte korrekt zurück. Bei der ODBC-Verbindung erhalte ich sie nur, wenn ich die ODBC-Verbindung direkt beim QueryTables.Add angebe. Wenn ich erst einen Recordset damit fülle, werden die Felder als adChar interpretiert.
Ich hab mir mal die Treiber-Einstellungen angeschaut, konnte allerdings die Screenshots hier nicht hochladen. Auffällig war z.B., dass bei der ODBC-Verbindung die OLE-DB-Version auf 2.00 stand, während sie bei der OLEDB-Verbindung auf 2.50 stand. Das könnte die Ursache für die Unicode-Probleme sein. Die ODBC-Treiber-Version stand auf 3.51 und müsste dafür ausreichend sein.
Um alle meine Probleme in dieser Sache zu lösen, werde ich nun also den OLEDB-Treiber mit Recordset und zum Daten einfügen den CopyFromRecordset verwenden. Somit kann ich alle Feldtypen verarbeiten, die Daten korrekt in die Ziel-Tabelle einfügen und auch aus Performance-Gründen die Connection offen halten.
Gruß,
KM