ODBC Verbindung AS/400

[akumm]

Hallo an alle,

ich habe zwar schon ähnliche Themen hier gefunden, aber diese waren mir immer etwas zu unausführlich, daher nochmal diese Frage.

Ich möchte mittels eines eigenen Programms (in meinem Fall mit VB) einen Connect zur AS/400 über den iSeries Access ODBC Treiber realisieren und ein paar Daten auslesen.

Nun gibt es ja mehrere Ansätze.
- ODBC.Connection
- ADODB. Connection

Bis jetzt habe ich ein DSN eingerichtet und schon ein paar Codeschnipsel geschrieben, aber ich bekomme einfach kein Connect hin.

ODBC:


Dim odbcCon As Odbc.OdbcConnection
Dim reader As Odbc.OdbcDataReader
Dim cmd As Odbc.OdbcCommand

strSQL = "SELECT ORDNO FROM MOMAST"

odbcCon = New Odbc.OdbcConnection("DSN=DSNname")
odbcCon.Open()
cmd = New Odbc.OdbcCommand(strSQL,odbcCon)
reader = cmd.ExecuteReader()
Do While reader.Read()
tmp1 = reader["ORDNO"]
Debug.print (tmp1)
Loop

reader.Close
odbcCon.close
Dann sagt er mir Benutzer ungültig und Password length = 0, muss ich die bei der ODBC.Variante noch irgendwo angeben?

Hat jemand eine ADODB Varinate parat?

:confused:

Viele Grüße
Andreas

[Fuerchau]

Deine ODBC-Klassen kenne ich (noch) nicht, aber mit ADODB gehts so:

dim myCnn as new adodb.connection
dim myRcd as adodb.recordset

myCnn.ConnectionString = "DSN=MyDSN"
myCnn.Properties("User Id")="MYUSER"
myCnn.Properties("Password")="MYPASSW"
myCnn.Open

set myRcd = myCnn.Execute("select ...")
do while myRcd.EOF=FALSE
myRcd.MoveNext
loop

In Verbindungsfolgen können meistens auch weitere Einstellungen vorgenommen werden:

"DSN=MyDsn;User Id=MYUSER;PWD=MYPASSW;"

Statt "User Id" geht auch manchmal nur "User" und bei "PWD" gaht auch häufig "Password". Das ist jedoch sehr treiberspezifisch.

Beachte noch den Unterschied zwischen ADODB und ODBC (.NET):
Bei ADO wird zwischen Client- und Server-Cursor unterschieden.
Ein Client-Cursor lädt beim Open bereits das gesamte Ergebnis in den Hauptspeicher, ein Server-Cursor holt Block/Satzweise.

Ein NET-Reader wirkt wie ein Server-Cursor, eine DataTable (o.ä.) wie ein Client-Cursor.

[akumm]

Vielen Dank für diese Infos. Das hat mir schon sehr geholfen.

Eine Frage noch zu Ihrem Tipp. Wenn ich die ADO-Variante wähle, wie entscheide ich nun (also Programmtechnisch), ob ich einen Server oder einen Client-Cursor verwende. Wenn ich ODBC verwende habe ich immer einen Server-Cursor? Hab ich das richtig verstanden?

Denn ich will natürlich unbedingt einen Server-Cursor und nicht den Speicher "vollmüllen".

Viele Grüße aus Berlin

[Fuerchau]

Nunja, das mit dem Speicher ist immer so eine Sache.
Die Doku und Beispiele zu ADO (MSDN) sind eigentlich ganz gut.
Schau mal im Windows-Verzeichnis unter Help/ADO210.CHM nach, das meiste gilt auch heute noch.

Es gibt je nach Anwendung Vor- und Nachteile für die Cursorart:

ClientCursor unterstützt Filter-/Find-/Move-Methoden sowie RecordCount/AbsolutePosition/Bookmark-Eigenschaften.

ServerCursor sind meist statisch (hängt vom SQL ab) und können nur dann auch nur vorwärts gelesen werden.

Die meisten Forms-Controls kommen mit Servercursorn überhaupt nicht zurecht.

Deshalb ist das in .NET ja auch abgeschafft, hier gibts eben die Reader zum reinen vorwärts lesen oder komplette Datenbankmodelle mit Tables/Relations usw. die nürlich auch komplett im Speicher liegen.

Desweiteren gibts bei ADO keine 64-Bit-Unterstützung mehr !!!
Wenn du dein NET-Programm dann mal auf einer 64-Bit-Maschine laufen läßt, funktionierts nicht mehr und NET-Programme können nicht im 32-Bit-Kompatibilitäts-Modus laufen (die CLR verhindert das).

Wenn du schon mit .NET anfängst, dann vergiss besser ADO und beschäftige dich mit den ADO.NET-Methoden.

Gute Literatur ist z.B. "Visual Basic 2005 & .NET 3.0" von Data Becker mit einem großen ADO.NET 2.0 Teil.