NULL-Werte auf String casten?

[Frederika]

Ich lese Daten mittels TADOQuery aus eine Datenbank (derzeit testweise Access, aber eigentlich unabhängig davon). Manche der Felder sind leider leer (NULL). Ich möchte beim Einlesen dieser Felder einen Leerstring erzeugen, erhalte aber immer einen Cast-Error ("Ungültige Variant-Typumwandlung").

Delphi-Quellcode:

var AFeld : String;
AFeld := myADO['Feld']);  // Fehler, falls Inhalt von 'Feld' = NULL
AFeld := String(myADO['Feld'])); // produziert den gleichen Fehler

Was muss man machen, damit es funktioniert?

[omata]

Schau dir mal

Delphi-Quellcode:

TADOQuery.FieldByName('spaltenname').AsString

an.

[Frederika]

Geht leider auch nicht...

Delphi-Quellcode:

AFeld := myADO['Feld'].AsString; // gleicher Fehler falls NULL
if myADO['Feld'].IsNull then AFeld := '' else AFeld := myADO['Feld']; // Fehler: "Variante referenziert kein Automatisierungsobjekt" ???

verzweifelt...

[omata]

Hast du gelesen, was ich geschrieben habe?

Delphi-Quellcode:

var AFeld : string;
begin
  AFeld := myADO.FieldByName('Feld').AsString;
  :

[Frederika]

Hallo Omata! Vielen Dank, hat tatsächlich geklappt. Super! Sorry, ich war auf das AsString fixiert, das bei myADO['Feld'] nicht funktioniert.

Worin unterscheiden sich denn die Zugriffe myADO['Feld'] und FieldByName('Feld')?

[alzaimar]

MyADO["FeldName"] liefert den Feldinhalt als Variant, wohingegen MyADO.FieldByName("FeldName") eine Instanz vom Typ TField liefert.

[Frederika]

Vielen Dank für die Erklärung.

Gibt es Performanz-Empfehlungen für die eine oder andere Art? Oder ist der Zugriff gleich schnell?

[haentschman]

Hallo,

unabhängig von der Lösung noch mein Senf dazu. :P
Ich persönlich mag keine NULL Werte in der Datenbank. Ich schreibe in sämtliche Felder beim neuen Datensatz zumindest Standardwerte. Wenn dann ein Feld NULL sein sollte, ist was schiefgelaufen :wink:

bis dann...

[Bernhard Geyer]

Zitat:

Zitat von Frederika

Gibt es Performanz-Empfehlungen für die eine oder andere Art? Oder ist der Zugriff gleich schnell?

Wenn du performance benötigst, schau dir mal die Kompos von DevArt an. Fall's du das letzte Prozent an Performance benötigst und auf TDataset-Kompatiblität verzichten kannst greif direkt auf die ADO-Schnittstelle zu und vergiss die Wrapper wie bei ADOExpress/dbGo.

[mjustin]

Zitat:

Zitat von haentschman

Hallo,

unabhängig von der Lösung noch mein Senf dazu. :P
Ich persönlich mag keine NULL Werte in der Datenbank. Ich schreibe in sämtliche Felder beim neuen Datensatz zumindest Standardwerte. Wenn dann ein Feld NULL sein sollte, ist was schiefgelaufen :wink:

bis dann...

Mit welchem Wert initialisierst Du das Feld 'Geschlecht', falls es unbekannt ist - mit 'männlich' oder 'weiblich'? ;)

Cheers,

[haentschman]

Zitat:

Mit welchem Wert initialisierst Du das Feld 'Geschlecht', falls es unbekannt ist - mit 'männlich' oder 'weiblich'?

:thumb: der ist gut.

mit Standardwerten meine ich "Standard" für den Feldtyp. Integer mit 0, String / Blob mit '' etc... Hauptsache nicht NULL.

PS: und wenn das Geschlecht '' ist, ist es entweder noch nicht zugeordnet...oder was anderes :gruebel: :wink:

[mkinzler]

Grundsätzlich macht der wert NULL aber schon Sinn.

[omata]

Zitat:

Zitat von haentschman

Ich persönlich mag keine NULL Werte in der Datenbank.

autsch! :wall:

Zitat:

Zitat von mkinzler

Grundsätzlich macht der wert NULL aber schon Sinn.

danke :thumb:

[Frederika]

Nochmal vielen Dank für Eure Antworten, vor allem Omata für die schnelle Lösung zu meiner Frage.

@Bernhard Geyer: Danke für den Link zu DevArt. Leider haben die nichts für Sybase.

[worker]

Zitat:

Zitat von Frederika

Leider haben die nichts für Sybase.

Ähm, Sybase bietet doch eigene Komponenten für den Zugriff an. Such mal nach adac oder Advantage DataAccessComponents.

[Frederika]

@worker: Davon verstehe ich irgendwie gar nichts. Ich programmiere wissenschaftlich, aber habe von Datenbanken leider nur SEHR begrenzte Ahnung (muss halt nur zum Austausch der Daten leider gemacht werden / riesige Molekulardaten). Unser Koop-Partner hat Sybase 9 -- was soll ich da mit dem Advantage Server? Ich bräuchte eher eine einfache Komponente, mit der ich direkt auf das vorhandene Sybase 9 zugreifen kann. Ich denke nicht, dass ich beim Koop-Partner mehr als mein Programm laufen lassen kann.

Derzeit nutze ich ADOQuery und ADOCommand, beides ohne visuelle Komponenten, es geht nur um das Wegschreiben eigener, komplexer Datenstrukturen (also daraus ausgewählten Ergebnissen) als schlichte Datenbanktabellen. Ein ebenso einfach zu verwendender, aber performanterer Ersatz für die beiden ADO-Komponenten wäre toll. Gibt es so was?

[DeddyH]

Du hast aber bemerkt, von wem der Advantage Database Server stammt, oder? ;)

[mkinzler]

Oder genauer, wer dieses Produkt aufgekauft hat.

[Frederika]

@DedyH: Klar habe ich das gesehen -- es mags ein, dass ich den Zusammenhang einfach nicht begreife, aber wenn ich von Delphi möglichst perfomant und simpel auf Sybase 9 zugreifen muss, was nützt dann der zusätzliche Advantage Server? Ersetzt der nicht eher Sybase? Oder was soll das ganze? Sorry, ich stecke in Datanbanken wirklich nicht drin und ADOQuery und ADOCommand sind sehr leicht zu bedienen und compilieren in den Code -- das gleiche in performanter wäre gut, aber ich kann auf Seiten des Partners nichts ändern.

[mkinzler]

Zitat:

was nützt dann der zusätzliche Advantage Server?

Nichts.

Zitat:

Ersetzt der nicht eher Sybase?

Sybase hat ihr Angebot durch ADS erweitert aber es ist eigentlich kein Ersatz.
ADO bietet sich eigentlich nur für Access und MSSQL an, für andere DBMS gibt es meist bessere Komponenten. Aber wenn die Auswahl nicht in deiner Hand liegt ist es müssig darüber zu diskutieren.

[p80286]

Zitat:

Zitat von Bernhard Geyer

Fall's du das letzte Prozent an Performance benötigst und auf TDataset-Kompatiblität verzichten kannst greif direkt auf die ADO-Schnittstelle zu und vergiss die Wrapper wie bei ADOExpress/dbGo.

Hallo Bernhard,

gibt es da irgendwo ein Delphi-Beispiel?
in google hab' ich nur die üblichen Verweise auf TADO... gefunden und Microsoft ist für Delphianer nicht ganz so ergiebig.

Gruß
K-H

[Frederika]

Zitat:

Zitat von mkinzler

ADO bietet sich eigentlich nur für Access und MSSQL an, für andere DBMS gibt es meist bessere Komponenten. Aber wenn die Auswahl nicht in deiner Hand liegt ist es müssig darüber zu diskutieren.

Na ja, Komponenten für mein Programm kann ich mir natürlich frei aussuchen, aber laufen muss das ganze dann mit Sybase auf einem fremden System ohne zusätzliche Installationen. Die Performanz ist derzeit ausreichend, aber wenn es empfehlenswerte Komponenten für direkten Zugriff auf Sybase 9 gibt, dann schaue ich mir sie gerne mal an. Vorschläge sind willkommen. Ich bräuchte nur Ersatz für TADQuery und TADOCommand -- mit den letzten Tipps hier aus dem Forum ist die Performanz jetzt aber ziemlich OK.

[Bernhard Geyer]

Zitat:

Zitat von p80286

gibt es da irgendwo ein Delphi-Beispiel?

Suche mal im http://www.entwickler-forum.de nach "CoConnection Kosch"

Zitat:

Zitat von Frederika

Na ja, Komponenten für mein Programm kann ich mir natürlich frei aussuchen, aber laufen muss das ganze dann mit Sybase auf einem fremden System ohne zusätzliche Installationen.

Dann geht es zu 100% nicht mit ADO da dieser standardmäßig keinen OLE DB Provider für Sybase mitbringt.

[FediDelPr]

Gemässe Alzaimar liefert MyADO["FeldName"] den Feldinhalt als Variant (siehe oben).

Warum gelingt mir dann die Zuweisung

VAR
such: VARIANT;
..
..

such := ADOQuery1['Suchwert'];

nicht.

Ist der Feldinhalt NULL, kommt die übliche Fehlermeldung:

Could not convert variant of type (Null) into type (OleStr)


Zurzeit arbeite ich mit FieldByName würde NULL aber gerne
explizit abfangen.

Tools: ACCESS recht neu, DELPHI Berlin

Danke für eine Begründung.

[Sherlock]

Gibt es kein

Delphi-Quellcode:

ADOQuery1['Suchwert'].IsNull

?

Verwendbar zB in einem if:

Delphi-Quellcode:

if not ADOQuery1['Suchwert'].IsNull then
  such := ADOQuery1['Suchwert'];

Sherlock

[Delphi.Narium]

Eventuell sowas:

Delphi-Quellcode:

VAR
such: VARIANT;
..
..
if not VarIsEmpty(ADOQuery1['Suchwert']) then such := ADOQuery1['Suchwert'];

[p80286]

@Sherlock
Soweit ich weiß, Nein!

NULL bedeutet ja, daß ein Feld leer ist. Das wiederum sollte in der Query abgefangen werden, falls notwendig. NULL ist eine Information, die nur in der DB existiert.
Mit dem

Delphi-Quellcode:

.Asstring

wird NULL zu einem Leerstring was aber nicht heißt, daß ein LeerString=NULL ist.

Gruß
K-H

[FediDelPr]

Danke für die schnellen Rückmeldungen.


Zusammengefasst komme ich nun zu folgenden Erkenntnissen:

VAR
such: STRING;

..
..

IF VarIsClear(ADOQueryAuto['Suchbegriff'])
THEN ShowMessage('not assigned')
ELSE ShowMessage('assigned');

IF VarIsEmpty(ADOQueryAuto['Suchbegriff'])
THEN ShowMessage('NULL')
ELSE ShowMessage('not NULL');

(* zwar einfach .. *)
such := ADOQueryAuto.FieldByName('Suchbegriff').AsString;

(* .. oder aus meiner Sicht besser *)
IF VarIsEmpty(ADOQueryAuto['Suchbegriff'])
THEN such := ADOQueryAuto['Suchbegriff']
ELSE such := '' (* .. oder etwas anderes *);

Es gibt keine Fehlermeldungen mehr und ich denke es läuft (ohne genaue Checks).

Etwas allerdings bleibt unbeantwortet. Warum wird die Zuweisung

vari := ADOQueryAuto['Suchbegriff'];

an den Typ VARIANT nicht akzeptiert ?
Ist der Term ADOQueryAuto['Suchbegriff'] evtl. gar nicht vom Typ VARIANT ?