Hallo,

ich teste seit einiger Zeit, die SQL-Direct Komponenten, für einen Umstieg von BDE auf SQL-Direct.

Beim TBlobField, sagt er mir allerdings dass er dieses nicht kennen würde. Ich habe darauf hin in dem Word File geschaut und gesehen, dass ich ein TSDCntrBlobField verwenden soll und dafür die Unit SDCTBLOB einbinden muss.

In dieser Unit möchte er eine SQLDir.Inc Datei einbinden, aber diese ist leider in der Demo Version nicht vorhanden.

Ist diese Datei in der gekauften Version vorhanden oder würde ich nach Kauf der Komponente an der gleichen Stelle anstehen?

Wie tief willst Du beim MS-SQL-Server einsteigen?
Falls es nicht zu tief ist dürften die von Borland mitgelieferten Komponenten ADOExpress/dbGo reichen.
Falls das nicht reicht solltest Du dir noch 2 Alternativen anschauen:
- Direkte Programmierung auf das ADO-Interface ohne Wrapper-Komponenten
- Die Komponenten von Corelabs wären auch ein Blick wert (Hab sehr Erfolgreich die Kompos bei MySQL im einsatz)

Hallo,

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. Vor allem weil diese auch eine WollToWoll Unterstützung anbieten.

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.

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.

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?

Zitat von GuenterS:

Vor allem weil diese auch eine WollToWoll Unterstützung anbieten.

Was sind das für Kompos. Kenne ich nicht.

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.

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.

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.

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.

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.

Zitat von GuenterS:

Zitat von alzaimer:

..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.

Genau darauf bezog sich mein letzter Satz