Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Delphi Wege weg von elevate DBISam? (https://www.delphipraxis.net/84836-wege-weg-von-elevate-dbisam.html)

ice.icewing 22. Jan 2007 15:45

Datenbank: DBISam • Zugriff über: DBISam-Komponenten

Wege weg von elevate DBISam?
 
hi,

Ich habe in den letzten beiden Wochen nach wegen gesucht ein SQL-DBMS für ein bestehendes Projekt nutzbar zu machen. Das Projekt nutzt im Moment elevate DBISam und das in mehr als einem drittel aller Units.

Nun habe ich einige Möglichkeiten gefunden, aber keine die mich wirklich glücklich macht.
1. 1/3 der gesamten Anwendung neu Programmieren (will ich nicht machen) :duck:

2. Die Klassen und Methoden des DBISam-Servers ersetzen. Das dieser sich zum Programm hin wie vorher verhält aber nach hinten an eine SQL-Datenbank geht.

3. Die DBISam-Client-bestandteile in ein Laufzeitpackage verfrachten und ein zweites Package schreiben das die SQL-funktionalität bereitstellt. Und sich zum Programm hin verhält wie das DBISam-Package. So das ich das dann austauschen könnte.

Ich hoffe, ich habe irgendeine offensichtliche und einfache Lösung übersehen.
Mir stehen die Quellen von allen drei Bestandteilen zur Verfügung.
Bevor es jemand sagt. Für 2 muss ich mir den Lizenzvertrag noch einmal ganz genau durchlesen. Wobei ich ja nicht dran denke einen Bestandteil zu verändern sondern alles bis auf die Methodennamen zu ersetzen.

Ein zweites nicht ganz so drückendes Problem sind die DBISam-Tabellen (*.Dat) die sich im laufe der Zeit angehäuft haben. Gibt es ein Tool diese in SQL-Tabellen z.B. für MySQL oder Oracle umwandeln zu können.


Noch einige Dinge auf die ich bei meiner Recherche gestoßen bin:
Bridge Pattern --> hab ich noch nicht ganz verstanden, scheint aber für Ansatz 1 und 3 Sinnvoll.

.Net --> Bisher ist hier alles mit Win32 programmiert und ich bin mir nicht sicher ob ich in dem Zusammenhang eine noch größere Baustelle eröffnen soll. (Noch dazu hab ich noch keine Erfahrung mit .Net. Auch nicht wie viel Arbeit es bei einem bestehenden Projekt macht dieses Umzubauen)

ODBC --> Wenn SQL dann allgemein gültig, aber Probleme:
Geschwindigkeit? (kann zu jetzt nur besser werden)
SQL-Dialekte (es ist für kein DBMS wirklich optimal)
Veraltet? (Ist es das wirklich und was ist besser?)

ADO --> Habe ich häufig gefunden jedoch noch nie benutzt. Ist es eine Alternative zu ODBC?

Zeos --> Tut sich da eigentlich noch was oder ist das Projekt eingeschlafen? Hab ich schon mal benutzt und war auch recht zufrieden, aber ich weiß nicht recht ob man das überhaupt noch braucht.

Local Interbase Server --> Habe in einem Buch gefunden das man damit DesktopDBMS auf ServerDBMS „Upsizen“ kann. Leider hab ich dazu rein gar nichts gefunden nicht mal wo ich es finden kann. Bringt mir das was und existiert es überhaupt?


Wenn ich Lösung 3 wähle hat da jemand eine Idee wie ich an das TDBISam-Table rangehen soll. Im SQL wird ja eigentlich alles in Querys gemacht.

So jetzt habe ich die meisten Fragen die sich mir in den letzten Tagen gestellt haben hier mal kund getan. Ich kann nicht erwarten das jemand auf alle Fragen antworten kann hoffe aber mir antworten viele auf einige der Fragen. Und vielleicht wären auch einige dieser Fragen durch besseres Recherchieren geklärt wurden, aber auch ich habe nicht ewig Zeit.

Danke schon mal im Vorraus, Jens

mkinzler 22. Jan 2007 15:55

Re: Wege weg von elevate DBISam?
 
Was für Komponenten sind DBIsam-spezifisch? Ist der Zugriff TDataSet-kompatibel?

QuickAndDirty 22. Jan 2007 15:56

Re: Wege weg von elevate DBISam?
 
Warum Willst du weg von DBISAM?
Wir wollen dahin. Was ist das Problem? Ärgerst dich über die Datumsfelder?

@MKinzler:
Ja dbisam ist nicht nur TDDATASET kompaptibel sondern stellt eine Obermenge zu TTABlE und TQuery Componenten dar. So das der Umstieg
von BDE zu DBISam recht gut laufen müste. Ich weiß nicht warum man von DBISAM weg wollen kann.

ice.icewing 22. Jan 2007 17:25

Re: Wege weg von elevate DBISam?
 
Es soll ja weiterhin nutzbar bleiben, nur sind wir momentan in der schlechten Lage keine alternativen Unterstützen zu können. Das Projekt ist halt von Anfang an mit den Komponenten programmiert.
Wenn es aber möglich wäre mit unserem Programm so wie es ist unsere Daten mit in der Oracle des Kunden ablegen zu können, so das diese dann auch wieder aus anderen Anwendungen (die halt kein DBISAM nutzen) genutzt werden können hätte das für uns echte Vorteile.
Ausserdem hat unsere Programmierabteilung einige Geschwindigkeitsprobleme im Multiuserbetrieb. Ich hab das noch nicht erwähnt weil ich es nicht auf die DB sondern eher auf die (mangelhaften) Optimierungen schiebe. Aber auch hier wäre es halt toll wenn man alternativen nutzen könnte (und sei es nur um festzustellen das es auch da nicht wirklich schneller wird).
Also wie du siehst wird es bei der Frage nach dem warum etwas schwammig. Aber es ist halt meine Aufgabe hier was zu tun (die Optimierungen kommen auch noch) und ich werde Versuchen (müssen) es hinzubekommen.

@QuickAndDirty: Wen ich dich neulich richtig verstanden habe, habt ihr euch auch die Möglichkeit geschaffen das DBMS austauschen zu können. Und so etwas ist auch mein Ziel. Vorrausgesetzt es gibt keinen Einfachereren Weg (So wie setze Parameter xy im DBISam_server und schon leitet der alles via ODBC an ein beliebiges SQL-DBMS.)

mfg Jens


Alle Zeitangaben in WEZ +1. Es ist jetzt 14:46 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz