ADO und BIGINT

[Ferdinand Klein]

Ich moechte ueber ADO auf eine DB2 Datenbank zugreifen. Hierbei gibt es Felder die als BIGINT definiert sind. Mit Q.Fields[x].AsInteger scheint es nicht so richtig zu funktionierten (Var Q: TADOQuery). Z.B wird ein negatives Vorzeichen bei Zahlen einfach ignoriert. Auch eine Konvertierung mit TLargeIntField(Q.Fields[x]).AsLargeInt hat keinen Effekt.

Wer kann mir helfen

Gruss Ferdinand

[Andreas Kosch]

Hallo,

die Kompatibilitätskomponenten TADOQuery und TADOTable sind nur dafür gedacht, eine alte BDE-Anwendung am Anfang einfacher auf ADO umstellen zu können. In einem "richtigen" Programm hat TADOQuery/TADOTable nichts zu suchen, sondern statt dessen ist <b>TADODataSet</b> bzw. <b>TADOCommand</b> die richtige Wahl.

Ich gehe davon aus, dass die Problem verschwinden, wenn TADODataSet verwendet wird. Wenn nicht, wird es wohl am verwendeten OLE DB-Provider/ODBC-Treiber liegen

[Ferdinand Klein]

Hallo Andreas,

erstmal Danke fuer die schnelle Antwort. In der Zwischenzeit habe ich noch einige Dinge ausprobiert. Die Verwendung von TADODataset hat leider den gleichen Effekt. Witzigerweise tritt der Fehler nicht auf, wenn ich die BDE-Komponente TQuery verwende. Aber eigentlich wollte ich die BDE hier nicht einsetzen. Ich habe das Ganze auch noch mit der direkten Verwendung der COM-Objekte (OleVariant conn = CreateOleObject('ADODB.Connection')) getestet. Auch hier tritt der Fehler nicht auf. Aus diesem Grund meine ich auch, dass der Treiber diesmal nicht Schuld ist.

So wie's im Augenblick aussieht habe ich wohl folgende Moeglichkeiten : die Datenbankleute davon zu ueberzeugen besser keine Felder vom Typ BIGINT zu verwenden, die gute alte BDE wieder an den Start bringen oder meine eigene Klasse basteln, welche das COM-Objekt kapselt.

Oder hast Du noch eine Idee, was ich versuchen koennte ?

Bis dann

Ferdinan

[Andreas Kosch]

Hallo,

<b>welcher</b> OLE DB-Provider wird im Connection-String für TADOConnection verwendet? Die ADO-Objekte Connection und Recordset setzen nur auf den darunter liegenden OLE DB-Provider auf, so dass das Gesamtverhalten in starken Maß vom Provider abhängt.

Im Fall des Microsoft SQL Server 2000 ist der Zugriff auf BIGINT problemlos möglich, wie das folgende Beispiel demonstriert. Delphi richtet für die BIGINT-Spalte der Tabelle ein <b>TLargeintField</b> ein:
<pre>
CREATE TABLE BigIntTest (
TLB_ID INT NOT NULL IDENTITY PRIMARY KEY,
Wert BIGINT NOT NULL)
</pre>
Konfiguration im Objektinspektor:
<pre>
object Form1: TForm1
Left = 286
Top = 107
Width = 696
Height = 480
Caption = 'Form1'
Color = clBtnFace
Font.Charset = DEFAULT_CHARSET
Font.Color = clWindowText
Font.Height = -11
Font.Name = 'MS Sans Serif'
Font.Style = []
OldCreateOrder = False
PixelsPerInch = 96
TextHeight = 13
object DBGrid1: TDBGrid
Left = 24
Top = 64
Width = 320
Height = 120
DataSource = DataSource1
TabOrder = 0
TitleFont.Charset = DEFAULT_CHARSET
TitleFont.Color = clWindowText
TitleFont.Height = -11
TitleFont.Name = 'MS Sans Serif'
TitleFont.Style = []
end
object DBNavigator1: TDBNavigator
Left = 136
Top = 32
Width = 240
Height = 25
DataSource = DataSource1
TabOrder = 1
end
object ADOConnection1: TADOConnection
Connected = True
ConnectionString =
'Provider=SQLOLEDB.1;Persist Security Info=False;User ID=sa;Initi' +
'al Catalog=tempdb;Data Source=(local)'
LoginPrompt = False
Provider = 'SQLOLEDB.1'
Left = 24
Top = 16
end
object ADODataSet1: TADODataSet
Active = True
Connection = ADOConnection1
CursorType = ctStatic
CommandText = 'select TLB_ID, Wert from BigIntTest'
Parameters = <>
Left = 56
Top = 16
object ADODataSet1TLB_ID: TAutoIncField
FieldName = 'TLB_ID'
ReadOnly = True
end
object ADODataSet1Wert: TLargeintField
FieldName = 'Wert'
end
end
object DataSource1: TDataSource
DataSet = ADODataSet1
Left = 88
Top = 16
end
end
</pre>
&#10

[Ferdinand Klein]

Hallo,

ich verwende folgende Funktion um eine Datenbankverbindung herzustellen :

function GetConnection:TADOConnection;
Var
conn : TADOConnection;
Begin
try
conn := TADOConnection.Create(NIL);
conn.LoginPrompt := FALSE;
conn.ConnectionString :=
Format('Provider=MSDASQL;DSN=%s',[VDatabaseName]);
conn.Open;
Result := conn;
except
Result := NIL;
End;
End;

Ich habe den ConnectionString von einem Kollegen uebernommen ohne mir ueber dessen Bedeutung gross Gedanken zu machen, da er bisher gut funktioniert hat.
Als Datentyp wird mir fuer das entsprechende Feld auch ftLargeInt angezeigt. Auch wenn ich das Feld mit TLargeIntField caste bekomme ich keine negativen Werte. Ich habe auch noch versucht den Wert des
Feldes mit GetFieldData dierekt auszulesen und bekomme hierbei folgende Werte : 222,0,0,0,0,0,0,0 (Buf : array[0..7] of byte)

Gruss Ferdinan

[Andreas Kosch]

Hallo,

hinter MSDASQL steckt der <i>Microsoft OLE DB Provider for ODBC Driver</i>, also läuft die Verbindung über einen ODBC-Treiber (genauer gesagt über die Reihenschaltung ADO -> OLE DB -> ODBC -> ORACLE-Treiber). Das schwächste Glied dieser Kette bestimmt das Gesamtverhalten.

Was passiert, wenn statt dessen der <i>Microsoft OLE DB Provider for Oracle</i> verwendet wird

[Ferdinand Klein]

Hallo,

die Sache wird leider immer verworrener. Urspruenglich laeuft das Programm unter Windows 2000 Server. Dort tritt auch dieser Fehler auf. Lasse ich das selbe Programm unter NT 4.0 laufen tritt der Fehler nicht auf.

Ich habe das ganze auch mit dem native OLE DB von DB2 (IBM OLE DB, Provider=IBMDADB2) vesucht. Bekomme dann aber die Meldung, dass der IBM OLE DB noch nicht verfügbar ist.
Nach langem Suchen im Internet habe ich herausgefunden, dass ich ein DB2 Bugfix > 1 verwenden muss um das ganze ans Laufen zu kriegen. Leider ist der zustaendige Server im Moment nicht erreichbar.

Ich habe auch noch versucht den Fehler zu beheben indem ich die neuste MDAC Version (2.6) eingespielt habe. Auch kein Erfolg.

Ist wohl nicht mein Tag heute.

Gruss Ferdinan

[Andreas Kosch]

Hallo,

vermutlich ist auf dem NT4-Rechner eine ältere MDAC-Version (2.1?) installiert. Windows 2000 wird mit MDAC 2.5 ausgeliefert und MDAC 2.5 unterscheidet sich definitiv im ODBC-Teil von 2.1