VB.NET mit OLEDB

[Miles]

Hallo zusammen,

ich versuche gerade eine Verbindung zu AS400 aufzubauen via OLEDB aber irgendwie funktioniert es nicht. VIA ODBC funktioniert es ohne Problem.

"Provider='IBMDA400';Data source=SYSTEM ;User Id=USERID Password=PASSWORD ;Protection Level=None;Transport Product=Client Access;SSL=DEFAULT;Force Translate=65535;Default Collection=LIB ;Convert Date Time To Char=TRUE;"

habe auch schon versucht den connetionString = "Provider=IBMDA400;Data Source=SYSTEM;User Id=USER;Password=PASS;" zu verkleinern.

Bekomme die Meldung das "IBMDA400-Provider ist nicht auf dem lokalen Computer registriert." kann mit dieser Meldung leider nix anfanfen.

Ich will daten per OLEDB in ein DATASET schreiben via SQL mit ODBC funktioniert es super, denke mit OLEDB sollte es schneller werden.

CA ist auf meinem Rechner komplett installiert.
Habe die Version:
Version 5 Release 2 Modifikationsstufe 0 mit SP SI04484.

Danke für eure Hilfe schon mal!

================================================== ==========================

Nachtrag:

meine programm in vb.net:

Option Strict Off
Imports System.Data
Imports System.Data.OleDb
Imports Microsoft.Office.Interop



Public Class Form1
Dim connetionString As String
Dim connection As OleDbConnection
Dim odbcAdapter As OleDbDataAdapter
Dim oledbCmdBuilder As OleDbCommandBuilder
Dim ds As New DataSet
Dim changes As DataSet
Dim i As Integer
Dim sql As String



Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
connetionString = "Provider=IBMDA400;Data Source=SYSTEM ;User Id=USER;Password=PASS;"
connection = New OleDbConnection(connetionString)


sql = "SELECT count(*) end FROM ALTGERFILE.ALTAS "
Try
connection.Open()
odbcAdapter = New OleDbDataAdapter(sql, connection)
odbcAdapter.SelectCommand.CommandTimeout = 6000
odbcAdapter.Fill(ds)
dgv1.DataSource = ds.Tables(0)
connection.Close()
connection.Dispose()

Catch ex As Exception
MsgBox(ex.ToString)
End Try

End Sub


End Class

[Fuerchau]

Stelle für deine .NET-Anwendung als CPU x86-32-Bit ein.
Auf einem 64-BIT-PC ist .NET automatisch auch 64-Bit und sucht dann nur den 64-Bit-Treiber.
Alternativ kannst du auch die 64-Bit-Version des CA installieren (falls verfügbar).

[Miles]

Habe ich Versucht aber bekomme die Meldung:
IBMDA400-Provider ist nicht auf dem lokalen Computer registriert!
Aber CA ist komplett installiert. :-(

[Fuerchau]

Geh noch mal in den Setup (selektive Installation) und prüfe den Haken für Datenzugriffskomponenten.
Alternativ müsste auch der IBMDASQL vorhanden sein.

Erstelle mal auf dem Desktop eine neue Datei "MYAS400.UDL". Per Doppelclick sollte ein Konfigurationsfenster aufgehen. Im Register Provider sollte die IBM-Treiber auftauchen.
Die UDL-Datei kann auch mit Notepad geöffnet werden, da sieht man dann mal den schönen Verbindungsstring.

[Miles]

Super mit der Datei "TEST.UDL", aber bei mir tauchen keine IBM-Treiber auf. :-(
Aber auf CA Installation ist alles selektiert.

[TARASIK]

Hallo Miles,
ich vermute es liegt an der Version R520 des ISeries Access. So wie mir bekannt ist, kam das mit R530 ISeries Access. --> Provider IBMDA400 is installed as part of Client Access V5R3M0
Welches Release hat denn die system i ? Wenn dort ein neueres Release installiert ist, dann könnte man von dort einen Update machen.

[Fuerchau]

Wenn du tatsächlich keinen OLEDB-Treiber zur Verfügung hast, dann nimm halt eine ODBC-Verbindung.
Für .NET gibt es da keinen Unterschied.

[Miles]

TARASIK, Danke für deinen Tipp. Werde mir mal die neue Version installieren.
Fuerchau, gibt es wirklich keinen Unterschiede?

[Fuerchau]

Nur geringfügig. Bei ODBC wird intern ein minimaler OLEDB-Treiber eingesetzt, der zwischen .NET und ODBC vermittelt.
Da aber weder ODBC noch OLEDB direkt von .NET verwendet werden können gibt es eben die .NET-Zwischenschichten.
Ansonsten bin ich persönlich schon immer besser mit dem ODBC-Treiber als dem OLEDB-Treiber zurecht gekommen, da der am Ausgereiftetsten scheint.
Insbesonders der Hickhack mit dem Call-Befehl beim OLEDB entfällt, da es nur den SQL-CALL gibt.

Da seit .NET 2.0 alle ADO.NET-Treiber von System.Data.Common erben sollten, ist es am Einfachsten, per
dim MyConnection as DBConnection
set MyConnection = new OLeDBConnection
zu arbeiten bzw. dieses in eine Funktion zu kapseln. Alles andere leitet sich dann aus der DBConnection ab.
Dann kann man einfach durch Austausch der Connection jederzeit die Datenbank wechseln (solange man sich an den SQL-Standard hält) oder falls mal verfügbar, den Basistreiber austauscht.

Übrigens kommt ab V5R4 ein ADO.NET-Treiber von ClientAccess mit den man aber nie und nimmer verwenden sollte!!!
1. ist es eher ein .Net-1.1-Trieber und 2. kann der noch nicht mal die einfachsten Schema-Abfragen wenn man sie nicht selber schreibt.
Zusätzlich werden keinerlei Frameworks (Entity o.ä.) unterstützt. Die IBM war da wohl einfach zu faul.

[Miles]

VIELEN DANK Fuerchau!!!