* MySQL -> Postgres: Datentypen und gängige Feldnamen

Datentypen:

Für die Migration einer älteren Faktura vom MySQL auf Postgres stellt sich als erster Schritt die Anpassung der Datentypen. Hier ein Vergleich der wichtigsten verwendeten Typen in MySQL 3.x und den entsprechenden Typen in  Postgres:

(je nach Version von MySql und Postgres können auch Abweichungen auftreten)

MySQL 3.x Postgres
INT, INTEGER INT (32 bit signed und BIGINT 64 bit signed) INT4
TINYINT TINYINT SMALLINT
FLOAT FLOAT (16 St., E+/-38 und DOUBLE 24 St., E+/-308) FLOAT8 (mit variabler Nachkommastellenzahl)
DECIMAL DECIMAL ohne Nachkommastellen NUMERIC mit variabler Nachkommastellen
NUMERIC DECIMAL ohne Nachkommastellen NUMERIC mit variabler Nachkommastellen
DECIMAL(p,s) / NUMERIC(p,s) DECIMAL mit vorgegebener Nachkommastellenzahl NUMERIC mit vorgegebener Nachkommastellenzahl
DATE DATE (yyyy-mm-dd) DATE (yyyy-mm-dd)
DATETIME DATETIME (yyyy-mm-dd hh:mm:ss) TIMESTAMP (yyyy-mm-dd hh:mm:ss)
CHAR(n) VARCHAR (bis 255 Zeichen) BPCHAR
VARCHAR(n) VARCHAR (bis 255 Zeichen) VARCHAR
BLOB, … BLOB (bis 64 KByte) / LONGBLOB (bis 4 GByte) als BYTEA oder via OID (Object Identifier)
UPPER / UCASE UPPER und UCASE UPPER
SYSDATE / NOW SYSDATE und NOW NOW()

Eine gute Seite mit weiterführenden Informationen ist hier zu finden:  http://en.wikibooks.org/wiki/Converting_MySQL_to_PostgreSQL

Gängige englische Übersetzung von Feldnamen und kaufmännischen Begriffen

Für gängige Übersetzungen von Feldnamen bietet SAP eine gewisse Orientierung.  Auf folgender Seite wird ein entsprechendes deutsch/english-Wörterbuch bereitgestellt:

http://www.home4sap.com/german-english.shtml

 

Einige gängige numerische Typen

Typ Größe/Speicherverbrauch Beschreibung Wertebereich von..bis
smallint 2 bytes 16 bit integer -32768 bis +32767
integer 4 bytes Standard Integer, passend für die meisten Fälle -2147483648 bis +2147483647
bigint 8 bytes besonders großer Integer -9223372036854775808 bis 9223372036854775807
decimal variabel Gleitkommazahl, genauer fast beliebige Anzahl Ziffern vor und nach dem Komma
numeric variabel Gleitkommazahl, ungenau fast beliebige Anzahl Ziffern vor und nach dem Komma
real 4 bytes Gleitkommazahl, ungenau 6 Ziffern Genauigkeit
double precision 8 bytes Gleitkommazahl, ungenau 15 Ziffern Genauigkeit
smallserial 2 bytes Autoincrement integer 1 bis 32767
serial 4 bytes Autoincrement integer 1 bis 2147483647
bigserial 8 bytes Autoincrement integer 1 bis 9223372036854775807

Postgres, Zeosdbo und Delphi

 

 

Momentan ist Zeosdbo das beste freie Tool zur Nutzung von Postgres unter Delphi.

Installation der Zeosdbo-Komponenten:

  • Öffnen des Projektes ZeosDbo in ../zeosdbo/packages/.. im zur Delphi-Version passenden Verzeichnis (“delphi7″ für Delphi7, “delphi11″ für Delphi 2007.
  • In der Projektverwaltung von Delphi die einzelnen Dateien kompilieren (nach rechtem Mausklicj auf Datei)
  • Abschließend ZComponentDesign*.bpl installieren
  • Fertig – die neuen Komponenten sind sichtbar in der Komponentenpalette

Leider traten bei mir im Test dadurch Probleme auf, dass beim Öffnen der Datenbanken/Tabellen unter Delphi das Fehlen der DLLs libpq81, libpq.dll moniert wurde, obwohl diese sowohl im Programmverzeichnis und in c:\windows\system32 (und in jedem anderen Verzeichnis das nur entfernt Sinnmachen könnte) vorhanden sind. Betroffen sind sowohl die Verbindungen zu lokalen Postgres-Installationen unter Windows 7 als auch die zu externen Postgres-Installationen unter Linux.

Da die DLL aber definitiv vorhanden ist, liegt der Verdacht nahe, dass beim Laden der DLL ein Fehler in den Abhängigkeiten vorliegt (z.B. Fehlen weiterer von libpq.dll genutzter DLLs).  Hilfe gibt hier das freie Programm Dependency Walker von Steve P. Miller.

Dazu die DLL libpd.dll in den Dependency Walker laden – die weiteren Abhängigkeiten bzw. fehlenden Module werden unten im Programm  angezeigt.

Eine Lösung ergibt sich dadurch aber nicht. Mein Verdacht war dann, dass es mal wieder an der 64 Bit-Version von Windows 7  liegt (Inkompatibilität der benötigten DLLs).

Folgender Ansatz führte zur Lösung:

  • Deinstallation des bestehenden Postgres-Installationen unter Windows. Neuinstallation der Version 9.1.1 (32-Bit).
  • Kopie aller DLLs aus dem bin-Verzeichnis (dort wo auch pgadmin liegt) in das Arbeitsverzeichnis der Delphi-Applikation.
  • Zusätzlich, damit Datenbankverbindungen auch aus der Delphi-GUI funktionieren:  Kopie der gleichen DLLs in das “Package-Ausgabeverzeichnis” – z.B.  C:\Users\Public\Documents\RAD Studio\5.0\Bpl.  -> Zu finden unter  “Tools-Optionen-Bibliothek-Package-Ausgabeverzeichnis”
  • Anschliessend konnte die Verbindung zur Datenbank ohne Probleme aufgenommen werden.

 

 

 

 

 

 

Leave a Reply

  

  

  

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>