Entwickler-Ecke

Datenbanken - Wie soll SQL Befehl aussehen bei versch. Schlüsseltypen?


JRegier - Do 09.06.05 09:54
Titel: Wie soll SQL Befehl aussehen bei versch. Schlüsseltypen?
Hallo, ich will dass meine Anwendung auf verschiedene DB'S zugreift!
Also z.B. jetzt MySQL mit Schlüssel wie TINYINT oder SMALLINT oder MEDIUMINT oder INT oder BIGINT

Wie sollte SQL Befehl aussehen wenn Schlüsseltyp unbekannt?


Delphi-Quelltext 
1:
2:
 
DataSet.SQL.Add('SELECT * FROM table WHERE id = :id');
DataSet.ParamByName('id').AsInteger := Value;  // var Value : Int64 ?


oder


Delphi-Quelltext 
1:
 
DataSet.SQL.Add('SELECT * FROM table WHERE id = '+IntToStr(Value));


iKilledKenny - Do 09.06.05 11:30
die paramter-property value solltest du benutzen. die ist vom typ variant und da kannst du reinschreiben, was auch immer du willst.


Delphi-Quelltext 
1:
 
DataSet.ParamByName('id').Value := MyValue;


viele grüße
alex


JRegier - Do 09.06.05 22:32
user profile iconiKilledKenny hat folgendes geschrieben:
die paramter-property value solltest du benutzen. die ist vom typ variant und da kannst du reinschreiben, was auch immer du willst.


Delphi-Quelltext 
1:
 
DataSet.ParamByName('id').Value := MyValue;


viele grüße
alex


Vielen Dank für die Aufschlußreiche Information! Aber was ist eigentlich mit der 2. Möglichkeit
also reines SQL+IntToStr(KeyValue) mache?


iKilledKenny - Fr 10.06.05 11:49
das sollte in diesem fall (int, bigint...) genauso funktionieren. die geschichte mit dem .Value geht für alle typen und ist daher universeller. bei strings z.b. müsstest du mit deiner methode auf ein QuotedStr achten (-> fehlerträchtig).

außerdem speichert dbms (z.b. oracle) sql-statements in einem cache, so dass parametrisierte abfragen schneller verfügbar sind.


JRegier - Fr 10.06.05 19:16
user profile iconiKilledKenny hat folgendes geschrieben:
das sollte in diesem fall (int, bigint...) genauso funktionieren. die geschichte mit dem .Value geht für alle typen und ist daher universeller. bei strings z.b. müsstest du mit deiner methode auf ein QuotedStr achten (-> fehlerträchtig).

außerdem speichert dbms (z.b. oracle) sql-statements in einem cache, so dass parametrisierte abfragen schneller verfügbar sind.


Habe es Ausprobiert!


Delphi-Quelltext 
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
 
procedure TDBAdminInterface.Operation(DataSet : TDataset; Operat : TOperation);
begin
    case Operat of
    NEW : FAdmin.SetKey(0);
    SELECT : FAdmin.SetKey(DataSet.FieldByName(FKey).AsVariant);  // habe hier auch statt
                                                                  // AsVariant -> Value prob.
    DELETE : FAdmin.Delete(DataSet.FieldByName(FKey).AsVariant);
    end;
end;


procedure TDBAdmin.SetKey(Value : Variant);
begin
   ...
   Query.SQL.Add('SELECT * FROM '+FTableName+' WHERE '+FRelKey+' = :PRM');
   Query.Prepare;
   Query.ParamByName('PRM').Value := Value;
   Query.Open;
   ...
end;


Fehlermeldung "Fehler im Typenausdruck" ... irgendwas

Habe dann die Tabellenstruktur angesehen die sind bei Delpi unter Samples in der Tabelle
LAGER das Feld Lieferant Nr ist ein "N" Typ aber ich sehe Fleißkomma-Zahlen mit ,00
und die wollte ich in meinem Programm mit LIEFERAN Feld Lieferant Nr verknüpfen

Gibt es überhaupt DB'S die andere Schlüsseltypen als Integer verwenden?


alzaimar - Fr 10.06.05 19:27
Erstmal erlaubt so ziemlich jede DB, fast alle Datentypen als Schlüssel zu verwenden. Wobei BLOBs (Binary Large Objects, also Bilder etc.) meist ausgeklammert werden.

Ob es SINNVOLL ist, z.B. die Kundennummer auch als Schlüssel zu verwenden sei dahingestellt. Ich persönlich mache das NIE. Aber Dein Problem ist ja auch unabhängig von irgendwelchen primary keys. Du möchtest einfach einen SQL-Ausdruck "FELD = <Wert>" für alle Datentypen und für alle Datenbanken syntaktisch korrekt erzeugen. Das ist nicht sooo einfach.

Aber, Du willst das, ohne grossartige Ahnung von den DBMS zu haben,. DAS ist das Problem. Natürlich gibt es einen Standard, also Strings in Quotes usw, aber beim Thema Datum fängts schon mal an. Ich kenne nur MSSQL gut, aber da ist das Datumsformat abhängig von den Einstellungen. Es gibt zwar ein universelles Format, aber ob das so SQL-Konform ist, das es auch andere DBMS verstehen... keine Ahnung.

Eigentlich musst Du dich darum gar nicht kümmern, weil das eigentlich der DB-Treiber übernimmt. Also ADO, BDE etc. Vielleicht bin ich grad zu blind, aber einen fundamentalen Fehler seh' ich in deinem Code nicht.

Ich gehe mal davon aus, das Du sowas wie einen Profiler hast. Damit solltest Du sehen, was genau zum Server geschickt wird. DAS schaust Du dir mal an. Und/oder postest es hier mal...


JRegier - Fr 10.06.05 19:34
Aber ich denke mal dass die meisten DB'S Schlüssel vom Typen Integer haben oder?

Was ist eigentlich wie ich jetzt erwähnt habe bei Fleißkomma-Zahlen eignit sich
der Datentyp Variant nicht?


alzaimar - Fr 10.06.05 19:38
Nee, die Frage ist falsch. Die 'Schlüssel' legt der Designer ja fest, also derjenige, der die Tabellen entwirft. Erlauben tut das die DB oder nicht. Aber, ich meine, erlaubt ist sogut wie alles. Ich habe z.B. eine Tabelle, deren Schlüssel ist ein Datum. Einfach, weil dann die Datensätze nach Datum sortiert abgespeichert werden. Bei der Datenanalyse nehme ich mir praktisch immer Datensätze innerhalb eines bestimmten Zeitraumes. Und da kommt der SQL-Server dann optimal ohne Zeitverzögerung an (Clustered Index).

Wie gesagt: Besorg Dir ein Programm, das die SQL-Befehle, die zum Server geschickt werden, anzeigt. Bei MSSQL heisst das Teil 'Profiler'. Ohne sowas sollte man IMHO keine DB-Anwendung entwickeln.

Was auch sein kann: Delphi nimmt das Komma als Dezimaltrennzeichen (z.B. 1,23), der SQL-Server will aber den Punkt (1.23)...


JRegier - Fr 10.06.05 19:48
Sprechen wir hier von dasselbe? Ich meine mit Schlüssel die eine Verknüpfung zur anderen
Tabelle darstellt! Wer würde z.B. ein String als Primary Key und Foreign Key nehmen?
Meist wird ja ein AoutoInc genommen und der ist ja ein Integer!


alzaimar - Fr 10.06.05 19:54
Wieso keinen String? Nichts spricht dagegen, außer der gesunde Menschenverstand. :D Wenn Du aber eine SW für verschiedene DB schreiben willst, dann kannst Du dich ja nicht drauf verlassen, das alle Tabellen, Primary und Foreign Keys von halbwegs Normalen entwickelt wurden, oder? Oder willst Du einfach eine Meldung auswerfen:
Zitat:
"Sorry, Ihre DB ist zu dämlich, sie wird von dieser Anwendung zu Recht nicht unterstützt, da sie offensichtlich von einem gehirnamputierten Waldschrat entworfen wurde"


JRegier - Fr 10.06.05 20:01
user profile iconalzaimar hat folgendes geschrieben:
Oder willst Du einfach eine Meldung auswerfen:
Zitat:
"Sorry, Ihre DB ist zu dämlich, sie wird von dieser Anwendung zu Recht nicht unterstützt, da sie offensichtlich von einem gehirnamputierten Waldschrat entworfen wurde"


Gute Idee!! :rofl:


JRegier - Sa 11.06.05 15:19
user profile iconJRegier hat folgendes geschrieben:
user profile iconalzaimar hat folgendes geschrieben:
Oder willst Du einfach eine Meldung auswerfen:
Zitat:
"Sorry, Ihre DB ist zu dämlich, sie wird von dieser Anwendung zu Recht nicht unterstützt, da sie offensichtlich von einem gehirnamputierten Waldschrat entworfen wurde"


Gute Idee!! :rofl:


Mit


Delphi-Quelltext 
1:
2:
3:
4:
5:
6:
7:
 
Query.ParamByName('PRM').Value := Value; // Funktionert doch nicht

// nur wenn ich so mach

Query.ParamByName('PRM').AsInteger := Value;

// dann ja


Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!