Am 14 Jan 2005 um 14:42 hat genz@cosymed.de geschrieben:

Hi

Am Fri, 14 Jan 2005 14:27:56 +0100 schrieb Michael Wenger :

...

AFAIK ist die beste Methode ein SQL-Dump der kompletten Datenbank. Dieser Dump enthält dann alle Daten in SQL-Anweisungen verpackt, sodass es "kein Problem" sein sollte, diesen Dump mit einer SQL-fähigen Datenbank zu importieren. Ich habe das bisher allerdings nur mit mySQL so praktiziert. Ob das bei Sybase möglich ist, weiß ich nicht.

Jupp das geht in Sybase auch.

UNLOAD [ FROM ] TABLE [ Eigentümer. ]Tabellenname TO Dateiname-Zeichenfolge [ Entladeoption ... ] LOAD [ INTO ] TABLE [ Eigentümer.]Tabellenname [ ( Spaltenname, ... ) ] FROM Dateiname_Zeichenfolge [ Ladeoption ... ]

Wenn dann alles fein in einem Script drin ist kann man eigendlich auch problemlos Daten in eine Sybase DB reinladen.

Das was ich eigentlich meine ist, dass ich nur ein Script (nach Möglichkeit) pflegen möchte. Es soll für verschiedene Datenbanken verwendet werden können. Ich denke da zusätzlich an PostgreSQL oder MSSQL. Es ist mir klar, dass es bei diesen Datenbanken Unterschiede gibt, aber gibt es auch gemeinsamkeiten, auf die ich mich konzentrieren kann ? Das Andere ist, dass ich die Installation so einfach wie möglich halten möchte. Bisher war mein Projekt nur für Entwickler gedacht, aber mit meinem nächsten Release denke ich auch an Endbenutzer. Sozusagen als Test und um Resonanzen zu bekommen. Gruß Lothar

gruss Henryk

--- Henryk Genz cosymed AG Web: www.cosymed.de Tel: 08407/93960

-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-programming-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-programming-help@suse.com

Am 14 Jan 2005 um 15:32 hat Michael Wenger geschrieben:

lothar.behrens@lollisoft.de schrieb am 14.01.2005 15:10 :

...

Das was ich eigentlich meine ist, dass ich nur ein Script (nach Möglichkeit) pflegen möchte. Es soll für verschiedene Datenbanken verwendet werden können.

Das kannst du doch machen.

Ack

...

Ich denke da zusätzlich an PostgreSQL oder MSSQL. Es ist mir klar, dass es bei diesen Datenbanken Unterschiede gibt, aber gibt es auch gemeinsamkeiten, auf die ich mich konzentrieren kann ?

Die Gemeinsamkeit ist SQL.

SERIAL <---> INTEGER NOT NULL DEFAULT AUTOINCREMENT

...

Das Andere ist, dass ich die Installation so einfach wie möglich halten möchte. Bisher war mein Projekt nur für Entwickler gedacht, aber mit meinem nächsten Release denke ich auch an Endbenutzer.

Du müsstest per Skript abfragen, welche DB der User benutzt und wo diese installiert ist.

Linux ist da weniger ein Problem für ein Script. Bei Windows fehlt mir die Erfahrung mit Installern. Ich verwende Inno Setup (Frei). Ich habe auch an Quellcode gedacht, der diese Entscheidung trifft. Dies sollte mit der ODBC API alles möglich sein.

Dann musst du in diese DB mit einem bestimmten Befehl den mitgelieferten SQL-Dump einspielen. Dieser Befehl unterscheidet sich wohl aber von DB zu DB. Man kann in Scripten Fallunterscheidungen machen...

Klar, aber benutzt ein User z.B. auch Perl als Script Interpreter (Windows) ?

Michael

BTW: Repariere bitte den Zeilenumbruch in Pegasus.

Sorry Lothar

Am 14 Jan 2005 um 22:32 hat Michael Wenger geschrieben:

Hi Lothar!

Von welchem Projekt sprichst du denn genau? Ich habe mal auf deine Seite geschaut und konnte nur DMF finden. Das scheint es ja nicht zu sein.

Doch. Darum handelt es sich. Ich erweitere gerade meine Demoapplikationen um eine Konfigurierbarkeit der Datenbankformulare über eine Datenbank. Dies ohne Probleme zu installieren, suche ich einen Weg, auch die Datenbank zu installieren.

Welche Zielgruppe willst du damit erreichen?

Zuerst Entwickler. Da aber (scheinbar) bis jetzt nur wenige mit mir Kontakt aufgenommen haben, versuche ich nun eine weitere - bessere Demoapplikation bereit zu stellen. Für die User.

Wie sieht der Inhalt deiner Datenbank aus bzw. wie herstellerspezifisch hast du sie aufgebaut? Hast du womöglich stored procedures verwendet, die den Import in andere DBMSe erschweren könnte?

Nichts spezielles. Nur Tabellen, in denen etwas zur Konfiguration steht. S. u.

Es ist nicht ganz einfach, vernünftig auf deine Fragen zu antworten, wenn man die Anforderungen nicht genau kennt.

lothar.behrens@lollisoft.de schrieb am 14.01.2005 22:01 :

...

Am 14 Jan 2005 um 15:32 hat Michael Wenger geschrieben:

...

lothar.behrens@lollisoft.de schrieb am 14.01.2005 15:10 :

...

Ich denke da zusätzlich an PostgreSQL oder MSSQL. Es ist mir klar, dass es bei diesen Datenbanken Unterschiede gibt, aber gibt es auch gemeinsamkeiten, auf die ich mich konzentrieren kann ?

Die Gemeinsamkeit ist SQL.

SERIAL <---> INTEGER NOT NULL DEFAULT AUTOINCREMENT

Was willst du mir damit sagen?

PostgreSQL verwendet SERIAL für automatisch gefüllte Primarykeys, Sybase kennt die andere Variante. Ansonnsten gab es nur noch Probleme mit der groß/klein-schreibung. Und dem Commit am Ende.

...

...

...

Das Andere ist, dass ich die Installation so einfach wie möglich halten möchte. Bisher war mein Projekt nur für Entwickler gedacht, aber mit meinem nächsten Release denke ich auch an Endbenutzer.

Du müsstest per Skript abfragen, welche DB der User benutzt und wo diese installiert ist.

Linux ist da weniger ein Problem für ein Script. Bei Windows fehlt mir die Erfahrung mit Installern. Ich verwende Inno Setup (Frei).

Ich kenne mich mit Windows-Installern auch nicht aus.

Inno Setup ist bis jetzt ausreichend. Es ist um sonst und ich komme damit zurecht.

...

Ich habe auch an Quellcode gedacht, der diese Entscheidung trifft. Dies sollte mit der ODBC API alles möglich sein.

Das setzt aber eine installierte DB und einen installierten ODBC-Treiber voraus.

Genau da ist das Problem. Einerseitz kann ich von einem Entwickler erwarten, dass Er/Sie dies bereitstellen kann. Es geht dabei nicht um das wie, oder mit welchem Script die Datenbank erstellt werden kann. Bis jetzt habe ich Entwickler anvisiert, aber weder gute noch schlechte Kritik geernted. (Ob Bugs/Tests/Probleme oder auch Verbesserungsvorschl.) Ich habe bisher nur einen aus den USA gehabt. Da glaube ich, ist aber der Kontakt verloren gegangen - oder keine Zeit...

...

...

Dann musst du in diese DB mit einem bestimmten Befehl den mitgelieferten SQL-Dump einspielen. Dieser Befehl unterscheidet sich wohl aber von DB zu DB. Man kann in Scripten Fallunterscheidungen machen...

Klar, aber benutzt ein User z.B. auch Perl als Script Interpreter (Windows) ?

Es kommt sehr auf die Zielgruppe an, die du bedienen willst.

Primär die Entwickler. Aber um es vollständig zu machen, auch die User.

Vielleicht solltest du auch nur eine "halbautomatische" Installationsroutine anbieten, wenn versiertere Nutzer die Zielgruppe bilden. Ich meine damit eine ausführliche, verständliche Anleitung, wie man deine Software installiert, das DB-Dump einspielt usw.

Alternativ könntest du natürlich eine Rundum-Sorglos-Lösung für weniger bedarfte User anbieten. Da würde ich dann aber gleich alles benötigte in einem Setup-Paket mitliefern, z.B. eben auch das benötigte DBMS. Der Benutzer würde dann eben nur angeben können, wohin alles installiert werden soll und den Rest erledigt das Setup-Skript für ihn: DBMS-Installation, Dump einspielen, Installation des restlichen Projekts würde ich dann eben ohne jegliche User-Interaktion durchführen.

Ich denke, beide Varianten sind brauchbar. Nicht alles wird mit jeder DBMS laufen. Aber was machbar ist, kann in einem 'gemeinsamen' Ansatz für Windows und Linux gelöst werden. Bis jetzt gehts.

Für ein solches Vorhaben ist diese Liste allerdings wohl der falsche Diskussionsort, weil wir hier doch sehr auf Linux/Unix spezialisiert sind. Du solltest dir dann eher Windows-Gurus suchen, die damit mehr Erfahrung haben.

Naja. Mein Ziel ist die platformunabhängige Softwareentwicklung. Es ist nur das Problem, so wenig wie möglich verschiedenes für die Platformen zu entwickeln. Ein Link, der mir den Unterschied im SQL Script gezeigt hat: http://troels.arvin.dk/db/rdbms/#mix-identity Vielleicht gibt es auch irgendwo Links zu Gemeinsamkeiten bei Softwareinstallationsprozessen. Im Grunde sind es doch nur die Abhängigkeiten von verschiedenen 'Subprojekten'. Auch wenn dabei eine ganze Datenbank installiert werden muss. Gruß Lothar Bin müde und gehe jetzt mal ein wenig pennen :-)