Ado - Umstellung auf andere Komponenten

[Astner Klaus]

Hallo zusammen,

ich hätte da mal eine Frage. Hat jemand Erfahungen mit der Umstellung von Projekten auf andere Zugriffskomponenten.

Meine Frage rührt daher. Wir nützen in unserer Software seit ca 8 Jahren nun ADO - Also die dbGo-Komponenten welche schon in Delhpi 5 drinnen waren. Wir sind damit eigentlich ja auch recht zufrieden, nur habe ich andst, dass wir damit irgenwann in den nächsten X Jahren probleme kriegen werden.
Wie seht ihr das ?

Ist vielleicht Herr Kosch auch zu einen Statement bereit ?
Welche alternativen zugriffe werden von Ihnen verwendet ?
Danke

[Bernhard Geyer]

Wenn du auf Access/MS SQL Server zugreifst ist unter Win32 ADO dies beste Art.

Um welches DBMS geht es denn?

[Astner Klaus]

MsSQL Mittlerweile 2008

Nur, wie lange kann man sich sicher sein, dass es fuktionieren wird ?
Ado ist tot heisst es immer ....
Und nachdem ich wirklich viele AdoDatasets in unserer Applikation verwende, möchte ich sicher gehen, dass ich nicht was anderes machen sollte.

Besteht irgendwie die Möglichkeit, über die normalen ADOExpress Komponetenen irgendwelche Klassen von Ado.Net zu verwenden? Denke da gibt es sicher nichts. Aber was machen die Entwickler von Software wenn irgendwann bestimmte Zugriffe nicht mehr unterstützt werden.

[Bernhard Geyer]

Ado ist tot heisst es immer ....
Und nachdem ich wirklich viele AdoDatasets in unserer Applikation verwende, möchte ich sicher gehen, dass ich nicht was anderes machen sollte.

ADO ist so tot wie native Win32-Entwicklung tot ist.

Besteht irgendwie die Möglichkeit, über die normalen ADOExpress Komponetenen irgendwelche Klassen von Ado.Net zu verwenden?

Nein.

Denke da gibt es sicher nichts. Aber was machen die Entwickler von Software wenn irgendwann bestimmte Zugriffe nicht mehr unterstützt werden.

Dann heißt es alternativen Suchen. Dann bist du aber vermutlich auch mit Delphi am Ende wenn die Win32-Entwicklung nicht mehr geht.

[Astner Klaus]

Auch wieder war.

Danke

[tinof]

Die Frage nach der Zukunft von Delphi beschäftigt mich auch massiv, das ist aber ein anderes Thema.
Für den Zugriff auf den SQL - Server verwende ich diese hier und möchte diese Kompos wirklich nie mehr missen.
Allerdings benutzen sie auch OLE-DB, was ja irgendwie wohl auch ADO ist.

Grüße
Tino

[Bernhard Geyer]

OLE-DB ist die zugrundeliegende Basistechnik von ADO. ADO ist "nur" die Programmierschnittstelle.

Und die Kompos von DevArts sind gut. Hab sie selbst bei MySQL im Einsatz.

[frauwue]

Hallo,

obwohl das Thema schon etwas älter ist, möchte ich es hier noch einmal aufgreifen.

Meine Situation:

Wir haben eine Sql-server 2005 Datenbank und etliche Zugriffsprogramme dazu. Die Programme wurden unter Delphi 7 unter Benutzung der BDE entwickelt. Unser Programm-System ist schon etwas älter und hat schon einige Umzüge hinter sich. (Verschiedene Delphi Versionen und ursprünglich eine INFORMIX Datenbank). Mittlerweile haben wir auch etliche Anwendungen in unserem firmeneigenen INTRANET laufen.

Hierbei kommt es aber ab und zu zu Engpässen, wenn zu viele Leute glecihzeitig damit arbeiten, wobei dann meistens nur ein Neustart des Intranet Servers hilft. Das liegt offensichtlich an der BDE, wie aus den Fehlermeldungen zu schließen ist.

Wir haben unterschiedliche Anwendungen zum einen Maskenprogramme (DLLs) zum Erfassen, die mit Delphi unter ATOZED Intraweb 8 entwickelt sind.

Dann gibt es noch reine Auswertungsprogramme (Delphi-exe - Files ohne sichtbare Maske), die über eine im Intranet integrierete Prozedur (HTML-Java) mit Parametern augerufen werden, ein Ergebnisfile erzeugen und dann sich selbst beenden. Das File wird dann wieder vom Intranet selbst angezeigt und gelöscht.

Ich benutze in den reinen Auswertungsprogrammen nur TQuerys.

Bei den die Maskenprogrammen arbeite ich zum Lesen und Schreiben auch nur mit Tquerys. Intraweb-DBgrids nehme ich nur zur reinen Anzeige.

Jetzt überlege ich, ob ich alles auf ADO umstellen soll, oder ob SDAC vielleicht besser ist. Unterscheidet sich SDAC von ADO nur durch komfortablere Komponenten? Oder ist die Performance auch besser?

Gruß

[tinof]

Hallo,

ich habe noch nie etwas mit DBExpress (ADO) gemacht, deshalb fehlt mir der gewünschte Vergleich.

Aber hier 'meine' Vorteile bei Devart (wobei ich nicht beurteilen kann, inwieweit manches auch bei DBExpress implementiert ist)

- Einfaches Handling von Connections
- Test der Statements und Anzeige der Ergebnisse direkt beim Design
- Getrennte SELECT, UPDATE und DELETE usw. Statements für gezieltes Arbeiten mit Gejointen Abfragen
- Makros im SQL - Befehl, sorgen teilweise für wesentlich schlankeren Code
- TVirtualTable kostenlos mit dabei: Zwischenergebnisse genau so behandeln wie Datenbankobjekte
- Threadsicherheit
- intuitive Programmierbarkeit

Grüße
Tino

[frauwue]

Hi Tino,

vielen Dank für die Antwort. Hört sich interessant an.
Ich werde mir dann mal die Trial-Version von SDAC herunterladen und es ausprobieren.

Gruß

[hwoess]

Kann's auch nur empfehlen. Arbeite jetzt seit etwa 1 Jahr damit und bin hochzufrieden. Überhaupt der SQL-Monitor, mit dem man sich ohne Zusatzaufwand alle Befehle (inkl. Parameter) ansehen kann, die eine Applikation zur Laufzeit so an die Datenbank schickt (wie der Profiler beim SQL-Server), haben mir schon ein paarmal sehr geholfen.

bye,
Helmut

[oldi46]

Probiers lieber nicht. Bei Programmen gibt s nur 2 Zustände.
Funktional bzw. NICHT Funktional. Halb Funktionierend ist NICHT-Funktionierend.
Wenn auch so manch ein funktionierendes Programm mittlerweile in die Jahre gekommen ist, so kann es einfach nicht verbessert werden.
Weder in Geschwindigkeit, Datenstabilität noch an Funktionalität sind irgendwelche Verbesserungen mit vertretbarem Auwand zu erwarten. Die Gefahr hingegen das es sich bei den unzähligen Nichtfunktioniernden einreiht ist Gigantisch groß geworden.
Auch die Vorteile alter Betriebssysteme und der Hardware sind nicht zu unterschätzen. Gerade in Betrieben wo Einzelplatzechner ohne Internetanschluß ihren Dienst tun. Geräte von Heute die 8- 15 Jahre durchlaufen sind nirgends wo mehr zu bekommen. Die Sicherheit zB. bei nicht unterstützten USB usw. Anschlüssen ,- abgeklemmte CD DVD Laufwerke , kleine Festplatten usw usw spart Sicherheitsausgaben, Experten Zeit und Geld.
Gruß

[frauwue]

Hallo,

ich habe inzwischen sowohl mit ADO als auch mit SDAC etwas herumprobiert. Geht eigentlich beides, da in den umzustellenden Programmen bisher hauptsächlich TQUERYS benutzt werden. Mir würde also die TADOQUERY ausreichen. Das einzige was mich hier stört, ist die Tatsache, dass bei AdoQuery.Fields[index].asstring (ebenso bei fieldbyname) die CHAR Felder rechts mit Blanks aufgefüllt werden. (Passiert bei SDAC nicht) Beim entsprechenden Googeln habe ich außer der Lösung mit Trim nichts gefunden.
Damit müsste ich sehr viel Code ändern.

Kennt jemand eine einfache Lösung (vielleicht eine Option), dies zu umgehen?

(Auf keinen Fall werde ich in der Datenbank alle Felder auf VARCHAR umstellen).

Gruß

[Bernhard Geyer]

Das einzige was mich hier stört, ist die Tatsache, dass bei AdoQuery.Fields[index].asstring (ebenso bei fieldbyname) die CHAR Felder rechts mit Blanks aufgefüllt werden. (Passiert bei SDAC nicht) Beim entsprechenden Googeln habe ich außer der Lösung mit Trim nichts gefunden

Eigentlich ist es ja die Definiton von chars das diese immer recht mit Leerzeichen gefüllt werden um die definierte länge zu erhalten. Würdest du direkt mit dem native ADO/OLE DB-Schnittstelle arbeiten würdest du das genauso bekommen.
Eigentlich verhält sich SDAC hier falsch da es ungefragt trimms vornimmt, aber evtl. kann man das ja per property konfigurieren. Für die dbGo-Komponenten ist mir so eine Option/Einstellung nicht bekannt.

[hwoess]

Das liegt aber nur an der "gutgemeinten" Default-Einstellung von SDAC. Da gibt es unter Optionen nämlich "TrimFixedChar" und "TrimVarChar" und "TrimFixedChar" ist defaultmäßig auf true. Man kann das also so einstellen, dass es sich wie ADOQuery verhält, kann's aber auch ändern (was sich zB. frauwue wünscht). Also in meinen Augen ein Plus für SDAC.

bye,
Helmut