CA ODBC und SQL Server 2005 SP3

[STAUBLI]

Hallo
Für unser Datawarehouse lade ich etliche Tabellen von der AS400 in den SQL-Server. Dies ging mit SQL2005 SP2 ohne Probleme seit SQL2005 SP3 ist es aber um ein vielfaches langsamer.
R5.4 aktuelles CA

Mit Microsoft habe ich das Problem eingekreist

Im ODBC-Trace sind für alle SQL_C_WCHAR Spalten, folgende Meldungen von IBM Treiber zu sehen:

DtsDebugHost 1474-1e20 EXIT SQLGetData with return code 1 (SQL_SUCCESS_WITH_INFO)
HSTMT 098F1F38
UWORD 4
SWORD -8 <SQL_C_WCHAR>
PTR 0x06E2A4F8 [ 2] "\ 0"
SQLLEN 2
SQLLEN * 0x0A6FF8B4 (4)

DIAG [22018] [IBM][iSeries Access ODBC-Treiber]Spalte 4: CWB0111 - Ein an einen Systemaufruf übergebener Puffer kann die Rückgabedaten nicht aufnehmen (30200)

DIAG [01004] [IBM][iSeries Access ODBC-Treiber]Zeichenfolgedaten rechts abgeschnitten. (30016)

Das hat sicherlich etwas damit zu tun, dass im .Net Framework Service Pack schärfere Bedingungen eingeführt wurden, was ODBC Spezifikation angeht. Es sieht so aus, dass hier die Zeichenlänge nicht richtig übergeben wird.

Ich komme nicht weiter, wer hat ein paar Ideen für mich?

Vielen Dank
Remo

[Fuerchau]

Das hat nichts mit dem NET-Framework zu tun.
SQL_C_WCHAR entspricht Unicode!
Damit müssen die Datenpuffer aber doppelt so lang angegeben werden was anscheinend hier nicht passiert und somit zu der Warnmeldung führt. Es kann auch tatsächlich zu Datenverlusten kommen.

Wie übergibst du die Daten dann ?
Machst du das per eigenem Programm oder über die ODBC-Verknüpfung im SQL-Server ?

[STAUBLI]

Ich lese die Daten der As400 über den .netDataProvider/ODBC Data Provider (Microsoft.SqlServer.Dts.Pipeline.DataReaderSource Adapter, Microsoft.SqlServer.ADONETSrc, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91), dieser geht über den IBM ODBC Treiber auf die As400.
MS-SQL seitig habe ich native OLEDB\SQL Client

Wo kann ich den Datenpuffer beeinflussen?

Danke

[Fuerchau]

Ich würde dir nicht den Umweg über den Provider des SQL-Server's empfehlen, der scheint da eher fehlerhaft zu sein.
Verwende entweder den CA-NET-Treiber direkt (ab V5 im CA enthalten) oder die nativen .NET-ODBC-Klassen.
Mit diesen hatte ich noch nie Probleme.

Eine Beeinflussung des Datenpuffers direkt ist leider nicht möglich, da dies die .NET-Klassen erledigen.

Ursache ist, dass SQLGetData einen Datenpuffer für die Übergabe benötigt.
In obigem Beispiel wird 2 übergeben, da die Feldlänge wohl 2 Zeichen ist.
Als WCHAR wird jedoch ein Puffer von 4 Byte benötigt!

Wenn es also mit dem vorherigen SP2 geklappt hat und nun mit SP3 nicht, würde ich den Fehler nicht bei anderen suchen sondern im SP3.

[STAUBLI]

Hallo Fuerchau

Im Moment werde ich zwischen IBM und Microsoft aufgerieben.

MS sagt es liege daran, dass IBM die Spezifikationen zu ODBC nicht einhällt und IBM, will mehr Geld um das Problem zu ergründen, da Sie das Problem bei Microsoft sehen.

Habe versucht direkt auf den ODBC Treiber zuzugreifen. Dies lässt der SSIS aber nicht zu. Er will für für die managed connection eine .net Schicht. Im Moment installiere ich einen neuen CA Patch(si35856). Wenn das auch nichts bringt, werde ich wohl anders Vorgehen müssen und ein eigenes Programm schreiben, das mir die Daten holt.

Wie genau holst Du die As400 Daten auf den SQL Server, wenn Du noch nie Probleme hattest?

Danke
Remo

[Fuerchau]

Schau mal zusätzlich hier nach:
Downloaddetails: Feature Pack f&#252;r SQL Server 2005 Dezember 2008

Da gibts eine DB2OLEDB-Treiber. Versuch den doch mal.

[Fuerchau]

Ich habe noch mal probiert.
Mit dem OLEDB-Treiber IBMDA400 funktioniert das auch ganz gut.
Die Konfiguration ist auch ganz einfach:

Als Datenquelle und Katalog gibts du den Systemnamen an, Produktname beliebig (ich habe einfach DB2/400 genommen) der Rest belibt frei.
Im Register Sicherheit ggf. noch Anmeldeinformationen.

Der DB2OLEDB funktioniert bei mir irgendwie nicht.

[STAUBLI]

Danke
Der kannte ich DB2OLEDB-Treiber funktionier aber nur mit Microsoft SQL Server 2005 Enterprise Edition und Developer Edition. Wir haben Standard.

OLEDB habe ich vor ein paar Jahren zugunsten von ODBC mal ausgeschlossen. Aber werde gleich noch mal Testen.

Alternativ teste ich auch noch die Treiber der Firma HIT.
Beriche sobald ich was weiss.

Danke
Remo

[Fuerchau]

Wenn alles nicht hilft, gibts wie immer mehrere Möglichkeiten.
Hier 2 Varianten:

a) Stored Procedure mit VB.NET/C#-Programm, dass selber die Daten als DataTable-Objekt zurückgibt
b) externes Programm, dass die Daten von AS/400 nach SQL-Server kopiert

Ansonsten gibts da noch diverse sog. ETL-Tools.

[STAUBLI]

Unsere Lösung wird ein OLE Treiber von HIT sein. Dieser ist funktioniert und ist sehr schnell.

Vielen Dank für Eure Hilfe