Seite 1 von 1

MySQL Daten Typen

Verfasst: Di, 07. Okt 2014 23:41
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

Re: MySQL Daten Typen

Verfasst: Mi, 08. Okt 2014 6:56
von Herbert
ist mit xbase 2 keine Erweiterung der Datentypen erfolgt?

Re: MySQL Daten Typen

Verfasst: Mi, 08. Okt 2014 7:06
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.

Re: MySQL Daten Typen

Verfasst: Do, 09. Okt 2014 1:29
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.