PostgreSQL <-> Arctica

[Martin Altmann]

Moins,
passend zum Thema: Die neue Beta 9 ist raus:
http://www.heise.de/newsticker/meldung/ ... 91643.html
Bietet auch eine Streaming-Replikation (quasi in Echtzeit).

Viele Grüße,
Martin

[Alfred]

In der Info findet sich folgende Information.

Wer seine Daten von einer Vorgängerversion auf PostgreSQL 9 migrieren will, muss sie mit pg_dump exportieren und anschließend in die neue Version importieren.

Dieser einfache Satz ist in der Praxis der absolute Horror, wenn der Server unter Linux läuft und man nicht selbst
Herr über die EDV ist.

Was der Satz nämlich verschweigt ist, dass der Dump parallel mit der alten Version erstellt und mit der neuen
Version importiert werden muss.

Und stellt euch einfach vor, ihr habt euer Programm mit 8.X erstellt und der Admin stellt freudig erregt auf 9 um,
weil dass eine andere Anwendung benötigt.


Gruß
Alfred

[brandelh]

Hi,

aber das erscheint mir völlig normal !

So geht es jedem Access Programmierer. Die DUMPS (zumindest die von MySQL) die ich
gesehen habe sind aber purer ASCII / Ansi Text. Für unsere Migration hatte ich ein
Programm geschrieben, das DBFs und MDBs (über SQLExpress) in DB2 Ladedateien
umgesetzt hat.

Du kannst in deinem Programm ja auch eine Update Routine vorsehen, die die Daten in DBFs
oder XML speichert.
Eine Datenbank ist nunmal keine Flatfile
Wenn du es anders willst und die Anzahl er User sich in Grenzen hält,
Pablo hat auf seiner Seite ein Beispiel für die Verwendung von SQLite -
eine einfache DLL, die die Daten in flat files speichert aber von außen per SQL angesprochen
wird. Sehr flexibel, aber als ich mich damit beschäftigt habe, gab es einige die die
Multiuserfähigkeit in Frage gestellt haben.
Ich habe mich für MySQL und ODBC entschieden, aber wenn man sich einliest und für kleinere Lokationen ... man braucht halt keinen Administrator sondern nur ein Verzeichnis.

[Martin Altmann]

Moin Alfred,
zum Einen ist das (wie Hubert schrieb) völlig normal und zum Anderen steht da noch ein wenig mehr
Man kann auch direkt migrieren...

Viele Grüße,
Martin

[Alfred]

Hallo Martin,
Hallo Huber,

zum Einen ist das (wie Hubert schrieb) völlig normal

wenn es so einfach wäre, würde ich nichts dazu schreiben.

Hier ein paar Hintergrundinformationen:

Bei allen andern Datenbanken macht man einen Dump mit der alten Version und
liest denn dann mit der neuen Version ein.

Progress will aber dass beide Server gleichzeitig laufen und das bedeutet,
das jeder Server seinen eigenen Port benötigt. Wenn man sein eigener Chef
ist kein Problem.

Unter Fedora ist es üblich, dass eine PostgreSQL dabei ist, nur die ist
in der Regel etwas älter. Das heißt also manuelle Installation ist angesagt
und dies kann nur der root.

Wenn beide PostgeSQL-Versionen auf dem Server bleiben müssen, muss einer
sein Programm ändern, da der Connectionstring den Port enthält.

Einfach migrieren ist unter Linux nicht möglich.


Gruß
Alfred

[brandelh]

Bei allen andern Datenbanken macht man einen Dump mit der alten Version und
liest denn dann mit der neuen Version ein.

so meinte ich das ...

Progress will aber dass beide Server gleichzeitig laufen und das bedeutet,
das jeder Server seinen eigenen Port benötigt. Wenn man sein eigener Chef
ist kein Problem.

das darf doch nicht wahr sein

[Martin Altmann]

Moin Alfred,
in einer so restriktiven Umgebung, wie Du das beschreibst, gibt es selbstverständlich mehr als einen Server!
Und dort wird natürlich nicht auf der selben Maschine aktualisiert, sondern eine zweite Maschine mit der neuen Version hingestellt, auf der der Dump der alten Version importiert wird. Schließlich will man ja auch problemlos zurück kommen, wenn es Probleme gab!
Und hat das dann gefunzt, hebt man den alten Server auf die neue Version und richtet ihn als Replikationsserver ein -> Hochverfügbarkeit.
Zumindest würde ich das (als Sysadmin in der Pflicht) so machen.

Viele Grüße,
Martin

[Alfred]

@Huber,

das darf doch nicht wahr sein

Ich bin bis Montag im Stress. Ich suche dass nächste Woche mal alles heraus.
Ich habe die ganzen Details und Fundstellen schon fast vergessen. Ich müsste
es aber sauber dokumentiert haben. Da PostgreSQL sehr kurze Updateinter-
valle hat(was ja nicht falsch ist), habe ich irgendwann das Handtuch geworfen,
da mir der Aufwand für eine Testumgebung zu hoch geworden ist.

@Martin

Kein Widerspruch. Ich denke Du merkst selbst, dass das alles einen EDV-Fachmann
vor Ort bedeutet. Entweder man selbst oder der Admin des Kunden. Ich denke
man muss bei seiner Entscheidung ob eine Datenbank für ein Programm eingesetzt
wird, sich sehr genau überlegen, ob man diesen Support auch zeitlich leisten
kann und es sich dann auch noch rechnet.

Gruß
Alfred

[Rudolf]

Hallo,
Tools zum anlegen von Tabellen, Datensicherung (Dump), Strukturänderungen etc. kann man leicht mittels SQL Befehle selbst schreiben, hab ich mit SQLEXPRESS und MySQL, MSSQL etc. problemlos geschafft. Auch das Übertragen der DBF Daten ist kein Problem. Die einzige Schwierigkeit sehe ich im Browsen grosser Tabellen. Die ODBCDBE ist vom Ansatz gar nicht so schlecht, man kann bei einer SQL Table SLQ Befehle nutzen oder die normale Datenbanknavigation von DBF Dateien. Leider ist das Ding komplett unstabil und nicht ausgereicht, hab ein grosses Projekt verloren weil Alaska wichtige Probleme nicht lösen konnte (wollte).
Ich erwarte mir durch SQL eine sichere Datenbank (obwohl ich mit DBF's noch nie Probleme hatte, aber meine Grosskunden haben eine andere Philosohie) und eine Erleichterung beim Arbeiten mit Teilbereichen aus einer Tabelle (Ersatz von Filter) sowie durch die Verwendung von Views, Trigger etc.. Bei diesen Dingen muss man eben umdenken, aber ein System wird dadurch sicherer, schneller und einfacher administrierbar. Dafür muss ein grosser Teil der Logik in der Datenbank enthalten sein. Für einen typischen DBF Entwickler ist das eine grosse Umstellung und ungewohnt, wo man bei DBF's alles selbst in der eigenen Software im Griff hat.
Bei einer Tabelle mit einer Million Datensätze und einem "SELECT * FROM ..." gibt es mit Sicherheit Probleme. Ich verwende für alle Dialoge Browser mit inkrementeller Suche, und die muss ich natürlich auch umstellen können. Habe Steffen diesbezüglich mal gefragt, anscheinend gibt es in Arctica dafür eine Lösung, ich denke der Browser im XBase++ muss dazu angepasst werden damit er im Hintergrund die Zeilen dynamisch nachlädt. Ich habe das mal für eine MSSQL Datenbank programmiert, ist aber viel zu komplex und langsam. Ich hoffe Arctica hält was es verspricht, sonst kann ich die Umstellung meiner Unmenge an Sourcecode vergessen, umschreiben auf SQLEXPRESS wäre zwar die beste Lösung (weil SQL unabhängig), würde aber Jahre dauern.
Wer sich mit PostgreSQL jetzt schon beschäftigen will, sollte es mit SQLEXPRESS probieren, funktioniert einwandfrei und der Umstieg fällt dann sicher leichter. Und Dokumentation ist massenhaft im Internet verfügbar.
Grüsse
Rudolf