MySQL Daten Typen

Alles zum SQL-Dialekt

Moderator: Moderatoren

Antworten
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

MySQL Daten Typen

Beitrag von AUGE_OHR »

in Xbase++ haben wir ja nur "C","M" ("V"),"N","L" und "D" während es in MySQL viel mehr gibt.

nun habe ich folgenden Konstanten und bin mir nicht sicher ob das jetzt schon so richtig ist.

Code: Alles auswählen

// Änderungen gegenüber Hectors original Class
case nNum == MYSQL_TINY_TYPE
   cTypeXbase := "L"

case nNum == MYSQL_DATE_TYPE        .OR.;
     nNum == MYSQL_DATETIME_TYPE    .OR.;
     nNum == MYSQL_NEWDATE_TYPE
   cTypeXbase := "D"

case nNum == MYSQL_SHORT_TYPE       .OR.;
     nNum == MYSQL_LONG_TYPE        .OR.;
     nNum == MYSQL_LONGLONG_TYPE    .OR.;
     nNum == MYSQL_FLOAT_TYPE       .OR.;
     nNum == MYSQL_DOUBLE_TYPE      .OR.;
     nNum == MYSQL_NULL_TYPE        .OR.;
     nNum == MYSQL_ENUMTYPE         .OR.;
     nNum == MYSQL_DECIMAL_TYPE     .OR.;
     nNum == MYSQL_INT24_TYPE       .OR.;
     nNum == MYSQL_YEAR_TYPE        .OR.;
     nNum == MYSQL_NEW_DECIMAL_TYPE .OR.;
     nNum == MYSQL_TIMESTAMP_TYPE
   cTypeXbase := "N"

case nNum == MYSQL_TINY_BLOB_TYPE   .OR.;
     nNum == MYSQL_MEDIUM_BLOB_TYPE .OR.;
     nNum == MYSQL_LONG_BLOB_TYPE   .OR.;
     nNum == MYSQL_BLOB_TYPE
     cTypeXbase := "V"

case nNum == MYSQL_VAR_STRING_TYPE  .OR.;
     nNum == MYSQL_STRING_TYPE      .OR.;
     nNum == MYSQL_SET_TYPE         .OR.;
     nNum == MYSQL_TIME_TYPE
   cTypeXbase := "C"
als "L" habe ich TINY_TYPE INT(1) statt wie bei Hector CHAR(1)
bei "D" habe ich das DATETIME_TYPE dazu was bei Hector auch Type "C" ist.

Frage : was ist NEWDATE_TYPE für ein Type ? ich hab es z.Z. unter "D" eingeordnet

was mir noch "fehlt" ist Type "M" was ich als MEDIUMTEXT definiert habe. klar ist es im Prinzip Type "C" aber für ein Memo nehmen wir ja ein MLE statt SLE.
die BLOB Typen habe ich nun als "V" definiert ( waren auch Type "C" ).

ist das jetzt alles "richtig" ? Kommentar erbeten, Danke
gruss by OHR
Jimmy
Benutzeravatar
Herbert
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1991
Registriert: Do, 14. Aug 2008 0:22
Wohnort: Gmunden am Traunsee, Österreich
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: MySQL Daten Typen

Beitrag von Herbert »

ist mit xbase 2 keine Erweiterung der Datentypen erfolgt?
Grüsse Herbert
Immer in Bewegung...
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: MySQL Daten Typen

Beitrag von georg »

Hallo, Jimmy -


und wieder einmal frage ich mich: "Wozu?"

Wenn ich für ein Programm SQL-Tabellen brauche, definiere ich (normalerweise) die Feldtypen, die ich auch in meinem Xbase++ Programm verwende. Da reicht das Mapping von Hector vollständig.

Alle Datentypen, die Xbase++ native nicht anbietet, muss ich ja irgendwie "umformen", um dann wieder bei den nativen Datentypen zu landen. Die Konvertierung hin und zurück kostet nur Zeit.

Es gibt zwei Bereiche, wo ich eventuell andere Datentypen brauche:

1. wenn ich in einem SELECT neue Felder erzeuge (SELECT (Anzahl * EKPreis) AS Position FROM auftrag) - dann kommt es schon mal vor, dass MySQL einen abweichenden Feldtyp zur Darstellung des Ergebnisses verwendet;
2. wenn ich externe Tabellen verwenden muss, die mit - für mich als Xbase++ Programmierer - non-standard Feldtypen arbeiten.

Und da lasse ich mir Zeit, bis ich den konkreten Fall vorliegen habe.
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: MySQL Daten Typen

Beitrag von AUGE_OHR »

georg hat geschrieben:und wieder einmal frage ich mich: "Wozu?"
weil die neue MySQL Applikation oft auf DBF Daten aufbauen die man übernehmen möchte.

mein Problem sind nun die Konstanten wo ich nicht genau weiss welchen MySQL Type die zugeordnet sind.

auch stellt sich die Frage ob ich den MySQL Type richtig anwende z.b. longBlob wo ich ein o:setbuffer()
in einen HEX String konvertiere (und zurück zur zwecks Anzeige).

werden Bilder "so" in MySQL abgelegt ... es funktioniert ja "so". (unabhängig vom Sinn)
georg hat geschrieben:Da reicht das Mapping von Hector vollständig.
das Type "L" als CHAR(1) und DATEEIME als Type "C" von MyResult betrachtet werden finde ich nicht logisch.

Deshalb frage ich ja nach den "richtigen" Daten Typen denn das ganz soll auch dazu dienen das ich später mit der Xbase++ Applikation auf "andere" MySQL Table zugreifen kann.
gruss by OHR
Jimmy
Antworten