Zitat von
Bernhard Geyer:
Zitat von
GuenterS:
danke für den Tip, die Corelabs Komponenten habe ich heute auch schon gefunden, aber der
BDE ähnlicher haben mir die
SQL-Direct Komponenten ausgesehen.
Beide sind TDataset-Nachfahren. Also was soll hier ähnlicher sein?
Mein Wunsch wäre es einfach nur die Komponenten auszutauschen, sprich in
dfm und
pas file ein search und replace machen zu können. TQuery nach TWasAuchImmerQuery usw.
Zitat von
Bernhard Geyer:
Zitat von
GuenterS:
Vor allem weil diese auch eine WollToWoll Unterstützung anbieten.
Was sind das für Kompos. Kenne ich nicht.
Das ist eine Komponentensammlung, welche diverse Datenbank gebundene Komponenten als auch eigene Queries, Tables, etc. anbietet. Beispielsweise ist es einfach in ein wwDBGrid (entspricht dem DBGrid mit einigen Erweiterungen), entsprechende Feldeditoren, wie LookupComboboxen, Checkboxen, etc. einzubauen.
Zitat von
Bernhard Geyer:
Zitat von
GuenterS:
ADO/dbGo hat doch auch andere Komponenten, welche sich nicht direkt austauschen lassen. Das Programm ist leider nicht gerade ein dreizeiler welches man einfach so auf die Schnelle für andere Komponenten umschreiben könnte. Deshalb suche ich auch Komponenten, welche denen der
BDE am ähnlichsten kommen würden.
Bitte aber nicht alle Krücken der
BDE mit den neuen Kompos weiterpflegen wie Filterung auf Client oder ähnliches.
Die
BDE Komponenten bieten eben auch eine TUpdateSQL Komponente an, welche wir an vielen Stellen verwenden. Genauso wie Filter. Ich möchte das nicht auf einen Schlag umschreiben müssen, wenn es denn auch anders geht.
Zitat von
Bernhard Geyer:
Zitat von
GuenterS:
Ich habe mir schon überlegt ob es nicht möglich wäre die ganzen
DB Komponenten selber zu schreiben und die notwendigen Aktionen eben über
ADO/dbGo oder direkt auszuführen. Ich bin mir nur nicht ganz klar darüber, wie die ganzen Datenbank sensitiven Komponenten damit umgehen sollen.
Ganz einfach. Wenn deine Kompos genau wie alle anderen von TDataset abgeleitet sind sollte das kein Problem darstellen. Ob sich aber der Aufwand für eigene TDataset-Kompos lohnt? Solche Zugriffskompos kosten ja nicht die Welt. Wenn schon was eigenes Bauen dann eine bessere
DB-Kapslung z.B. mit Bridge-Pattern.
Ja, leider ist das Schreiben eigener Komponenten wahrscheinlich ein richtiger Aufwand, welcher sich vermutlich auch nicht lohnen wird. Sehe das nur als letzten Ausweg.
Zitat von
alzaimer:
Beim Umstieg von
BDE auf
ADO habe ich mir einmal einen Translator geschrieben: Der hat die
DFM übersetzt, in dem er einfach aus TDatabase-Komponenten eine TADOConnection, aus TTable eine TADOTable etc. gemacht hat. Ja gut eh, ein Paar sachen waren auch noch dabei, denn eine TADOTable hat keine 'Database' Eigenschaft, dafür aber eine 'Connection'. Und da ich ja sowieso die TDatabase-Komponente in TADOConnection umwandeln muss, war das nicht sooo schwer.
Bei der TDatabase-Komponente war ein bischen mehr Arbeit nötig (so ca. 10 Zeilen).
Damit ließen sich (ich hab keine TSessions verwendet) 99% der
DFM problemlos anpassen. Der Rest war Handarbeit.
Beim Code war es etwas kniffeliger, weil (soweit ich mich erinnere) die Parameter und die Feldzugriffe irgendwie anders geregelt waren (Ich meine, es erschöpfte sich im Austausch von [] mit ()). Insgesamt war ein ca. 50000 Zeilen-Projekt in 30 Min auf
ADO umgestellt. Ok, am Translator hab ich vorher 1-2 Stunden gesessen, aber die 'Mühe' war es wert. Gottseidank waren alle
DB-relevanten Programmteile schon damals von mir streng modular in Datamoduln ausgelagert. Lohn sich schon...
Erstaunlicherweise lief die Anwendung anschließend sogar. Laughing
Ich werde diesen Thread jedoch zum Anlaß nehmen, mir die hier vorgestellten Komponenten anzuschauen, weil ich mit der Umsetzung von
ADO in DML nicht zufrieden bin.
Wenn an jetzt nur TTable und TQuery Komponenten verwendet hat, mag das ja auch super funktionieren. Jedoch bietet
ADO keinen Ersatz für die TUpdateSQL Komponente. Hat man diese verwendet, ist natürlich auch etwas mehr Aufwand notwendig.