ADO und Int64

[Knut Lambert]

Hallo zusammen,

ich benutze D5/Enterp. mit Oracle (7 u. 8).

In meinen Tabellen sind die Schlüsselfelder mit NUMBER(15) deklariert. Davon werde 14 Stellen immer benutzt. (Die ersten drei Stellen schlüsseln etwas der Rest ist ein Zähler! Der Kunde will es so!!)

Beim Zugriff auf die Felder kann ich in D5 mit

AdoQuery.FieldByName('IDFIELD').asLargeInt arbeiten. Aber Parameters.ParamByName('IDFILED').asLargeInt geht nicht!

Das ist auch bei AdoStoredProc so. Mit Parameters.Items[0].DataType bekomme ich zwar die Info ftLargeInt, kann das aber in Delphi nicht auswerten. Ich bekomme zwar mit Mit Parameters.Items[0].Value einen Wert. Ist aber vom Type OleVaraint.

Irgenwie scheint mir da eine Info zu fehlen. Keine Ahnung, wie ich da weiterkomme.

Vielen Dank für eure Hilfe

Knut Lambert (lambert@consilium.de)

[Andreas Kosch]

Hallo Knut,

tja - wie ich immer schon sage: Luxus schafft Probleme (Int64)! Da mir noch nie eine Oracle-Datenbank zur Verfügung stand, ist meine Antwort rein theoretischer Natur ;-)<br>
Prüfe einmal die folgenden Konfigurationseinstellungen:

TADOQuery.Parameters: TParameters;<br>
-> TParameters.Items[Index: Integer]: TParameter;<br>
-> TParameter.Attributes (?) <br>
-> TParameter.DataType (<b>ftLargeInt</b>)<br>
-> TParameter.Direction (<b>pdInput</b>)<br>
-> TParameter.NumericScale (?) <br>
-> TParameter.Precision (?) <br>

Die Eigenschaft <b>TParameter.Value</b> sollte nur dann verwendet werden, wenn der Datentyp zur Compilierungszeit unbekannt ist, denn dann ist <b>OleVariant</b> als universeller Typ genau richtig

[Knut Lambert]

Hallo Andreas,

Du hast recht! Das ist ein Luxus gegen den ich mich mit Händen und Fuessen gewehrt habe. Aber, Du kennst das ja. Wer die Zechhe bezahlt, darf auch die Spielregeln festlegen. Noch schlimmer ist, dass hier in einem PrimaryKey in einem Feld zwei Infos codiert sind. Codd würde sich im Grabe umdrehen!

Die folgende function feuert eine StoredProcedure welche die nächste
ID für eine Tabelle in einem bestimmten Land (Unit) liefert.

Im Moment ist TIdFieldType : Comp; Ist aber an vielen Stellen
unhandlich (e.g. FloatToStr, asFloat, Vergleich auf Gleichheit etc.).

v musste ich deklarieren obwohl in der Doku steht, das nil funktioniert! Geht aber nicht (OleVaraint und Pointer inkompatibel)

Ändere ich jetzt TIdFieldType zu Int64 kann die Function wegen
inkompatibilität zwischen Int64 un Variant nicht kompiliert werden.

Im Moment sehe ich das so, dass Int64 nicht zu verwenden ist!

function Next_Id (TableName : string; UnitId : TIdFieldType = -1) : TIdFieldType;
var
v : OleVariant;
stpNextId: TAdoStoredProc;

begin
stpNextId := TAdoStoredProc.Create (nil);
with stpNextId do
try
Connection := dmSims.OraConnection;
ProcedureName := 'GET_NEXT_ID';

Parameters.CreateParameter('NEXTID', ftLargeInt, pdOutput, 15, v);
Parameters.CreateParameter('TABNAME', ftString, pdInput, 30, v);
Parameters.CreateParameter('UNITID', ftLargeInt, pdInput, 15, v);

Parameters.ParamValues['TABNAME'] := TableName;
Parameters.ParamValues['UNITID'] := UnitId;

ExecProc;
Result := Parameters.Items[0].Value;
finally
Close;
Free;
end;
end;

Schreibe ich jetzt an anderer Stelle (mit TIdFieldType : Int64;):

AdoQuery.FieldByName('IDADDRESS').????? := IrgendEinInt64;

.. wird das Chaos komplett! Nothing goes more!! Irgendwie hat Borland da was für Delphi 5.01 übrig gelassen!

Wäre schön, wenn Du da eine Idee hättest

Übrigens, was macht Dein neues Buch? Wird ADO schon behandelt?

Mit besten Grüßen

Knut Lambert
(lambert@consilium.de

[Andreas Kosch]

<p>Hallo Knut,</p>

<p>in Deinem Beispiel wird die <strong>TADOStoredProc</strong>
erst zur Laufzeit dynamisch erzeugt, so daß Du alle
Konfigurationen &quot;blind&quot; im eigenen Sourcecode vornehmen
mußt. Wie sieht das Ganze aus, wenn alles visuell via <em>Objektinspektor</em>
konfiguriert wird. Welchen TField-Typ legt der <em>Delphi-Feldeditor</em>
für das persistente TField der Int64-Tabellenspalte an (siehe
das folgende Beispiel - allerdings ohne Int64)?</p>

<pre> object ADOQuery1: TADOQuery
Connection = ADOConnection1
Parameters = &lt;&gt;
SQL.Strings = (
'SELECT * FROM ORDERS')
Left = 56
Top = 32
object ADOQuery1OrderNo: TFloatField
FieldName = 'OrderNo'
end
object ADOQuery1ShipDate: TDateField
FieldName = 'ShipDate'
end
end</pre>

<p>Und kann der Int64-Wert für die <strong>TADOStoredProc</strong>
verwendet werden, wenn alles zur Entwicklungszeit visuell via <em>Objektinspektor</em>
konfiguriert wird? Normalerweise sollte sich der Parameterwert
hier fest zuordnen lassen, so daß ein bestimmter Datensatz fest
eingetragen werden kann. Falls dies funktioniert, wäre hier auch
der richtige Ort, um nachzuschauen, welche Konfiguration dabei
Delphi intern verwendet hat.</p>

<pre> object ADOStoredProc1: <strong>TADOStoredProc</strong>
Connection = ADOConnection1
Parameters = &lt;
item
<strong>DataType = ftLargeint</strong>
<strong>NumericScale = 15</strong>
Value = 150000
end
item
DataType = ftInteger
NumericScale = 15
Value = Null
end&gt;
Left = 56
Top = 64
end
end</pre>

<p>Sollte das auch nicht funktioneren, würde ich auf das
Kompatibilitätsobjekt <strong>TADOStoredProc </strong>verzichten
und gleich zu <strong>TADOCommand</strong> etc. greifen.
Allerdings taucht dort auch wieder <strong>Parameters</strong>
auf.</p&gt

[Knut Lambert]

Hallo Andreas,

Habe das Problem hin und her getestet. Der Type int64 ist wirklich nur als solcher zu gebrauchen. In Delphi-Datenbankapplikationen (mit den Delphi Komponenten) ist er völlig unbrauchbar!

Habe heute einige Stunden verschwendet um eine Lösung zu finden. Ich bleibe bei Comp! Int64 ist weder zu Variant noch zu Olevariant konvertierbar. Int64 ist eigentlich zu garnichts konvertierbar!

var
id : comp;
begin
if DataSet.State <> dsBrowse then Exit;
with ADOStoredProc1, Parameters do
begin
Items[1].DataType := ftLargeInt;
Items[1].NumericScale := 15;

// Das geht noch
Items[1].Value := 999999999;

// Das benötige ich! Geht aber nicht!
Items[1].Value := 101000000000002;

// Das geht
id := 101000000000002;
Items[1].Value := Id;

ExecProc;
Caption := ParamValues['RETURN_VALUE'];
end;
end;

Also werde ich weiterhin die Ungleichheit von IDs mit der Methode

if (ID1 - ID2 > 0.0001) then ... (Tip aus Borland FAQ!!!)

feststellen! ;-)

Dank Dir für Deine Mühen.

Ich habe im übrigen einige Tests mit ADO und Oracle gemacht. Ist performanter als die BDE! (Datenbank aus 110 Tabellen (je zwischen 5.000 und 120.000 Datensätzen und, und ...)

Einge Dinge funktionieren wohl nicht!

z.B:

SELECT * FROM TABLE FOR UPDATE NOWAIT

und schon hat man ein Problem mit einer unverstänlichen Fehlermeldung!

Ander sind gut! Positionierung des Cursors nach einem Insert etc.

Wir werden sehen!

Viel Spaß bei allem

Knut Lambert
(lambert@consilium.de