Georg hat geschrieben:Meine private Meinung: Alaska hat für die PostgreSQL-Implementierung die SQL-Tabellen derart vergewaltigt, dass man schon fast nicht mehr von einer SQL-Tabelle sprechen kann.
Prokrustes fällt mir dazu nur ein.
Wenn Du Dir die Mühe machst, Dein Programm auf SQL umzustellen (z.B. über Hector's Wrapper) dann gewinnst Du deutlich mehr - aber, je nach Grösse des Projekts, ist der Aufwand auch nicht trivial. Aber zukunftssicher.
da stimme ich voll zu
Falls du SQLExpress() in Betracht ziehst, kannst du deine Anwendung sogar unabhängig vom SQL Server machen (MySQL z.B. auch nutzen), allerdings muss man sich dann auf das beschränken, wa bei beiden gleich ist.
AUGE_OHR hat geschrieben:
es gibt, von Phil Ide, eine Class welches die native PostgreSQL Schnittstelle per API benutzt.
diese habe ich mit Hilfe von Pablo, Edgar und Hector mittels ot4xb in PGU.EXE / DLL zusammengefasst. (siehe Wissensbasis)
das ist irgendwie an mir vorbei gegangen ... allerdings ist Hektors/Georges Umsetzung der API jünger, PHIL ist leider nicht mehr aktiv (oder gar schon gestorben).
georg1956 hat geschrieben:Gibt es ein Modul mit dem ich, ohne den Quellcode großartig umschreiben zu müssen, PostgresSQL Datenbanken ansprechen kann.
eigentlich sollte dafür schon die OCDBDBE ausreichen, mit der bin ich aber nie warm geworden. Ich persönlich ziehe eine Lösung mit einem Datenbankobjekt wie SQLExpress() vor.
sicherlich muss man den Code umstellen, aber SQL ist einfach eine andere Welt. Man gibt dem Server nur vor WAS man möchte, wie er dazu kommt geht uns nichts an.
Mit Xbase++ konnte man ja auch mit (fast) keinen code Änderungen eine Programm von CLIPPER-DOS nach WIN32 bringen. Das stimmt und es funktioniert !
Dieses Programm kann aber nicht mehr als bisher, wenn man mit der alten Optik zufrienden ist und kein CUT & PASTE will geht das auch wirklich gut.
ABER ES BLEIBT EIN ALTES DOS PROGRAMM !
Keine Fenster, keine GUI, wer mehr will muss Teile ändern.
Hierbei nimmt man dann idealer Weise auch die Programmlogik genau unter die Lupe, was unter DOS alle möglichen umständlichen Verrenkungen (mehrere Fenster, Speicherplatz etc.) benötigte
geht nun nach einem Redisign ganz einfach.
Ähnlich ist es auch mit den Daten, altes DBF/NTX/CDX Denken (erst das, dann das ...) sollte man gegen mengenorientiertes Denken austauschen.
Sicherlich ist nicht alles Gold was glänzt, aber wenn man den Umstieg erledigt hat, kann JEDER SQL Admin mit der Datei umgehen,
andere Anwendungen (egal mit welcher Sprache) können mit der Datenbank zusammenarbeiten.
Das geht nicht, wenn man den UPSIZE Prozess genutzt hat, zwar wird Alaska wohl mit triggern und ähnlichem den Betrieb so kompatibel wie möglich machen,
aber wenn man einem Admin erklären soll was er alles davon nicht anrühren darf ... oder noch besser wofür es gut ist ...