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]

Während das bei SQL-Server unter Garantie früher oder später (eher früher) Deadlocks auslöste war das bei Oracle kein Problem.

Wars vieleicht noch eine Version ohne Multi-Version-Konzept (Konkretes Fachwort weiß ich jetzt nicht). Hab mich auch gewundert das das MS erst in der 2005er geschafft hat zu implementieren. Davor konnt man relativ einfach Deadlocks provozieren.

[hwoess]

[Off-Topic]
Zitat:
Zitat von hwoess Beitrag anzeigen
.... und für die Oracle-Anhänger ...
Was, die gibts? Ich würde mehr kennen die Oracle verfluchen würden ...
[/Off-Topic]

Wie heißt es so schön? ... it depends...
ich hatte vor einigen Jahren mal einige Zeit für eine Softwarefirma gearbeitet, die eine Warenwirtschaft für Telefonkonzerne schreibt. Da hängen dann hunderte von Telefonshops am Zentralserver und es kommt daher zu vielen gleichzeitigen Zugriffen. Während das bei SQL-Server unter Garantie früher oder später (eher früher) Deadlocks auslöste war das bei Oracle kein Problem. Da kann man dann mit diesem Leerzeichenproblem wieder gut leben

bye,
Helmut

[Bernhard Geyer]

Naja, das Umwandeln von Leerstrings zu NULL in Oracle kann man wohl nicht ganz damit vergleichen, es gab nämlich keine Einstellmöglichkeit, um das zu ändern.

Hatten das gelöst das ein leerzeichen hier ein leerer String.
Dumm nur das nach einiger Zeit konstelationen aufgetreten sind das dieses leerzeichen "wegoptimiert" wurde.

[Off-Topic]

.... und für die Oracle-Anhänger ...

Was, die gibts? Ich würde mehr kennen die Oracle verfluchen würden ...
[/Off-Topic]

[hwoess]

Naja, das Umwandeln von Leerstrings zu NULL in Oracle kann man wohl nicht ganz damit vergleichen, es gab nämlich keine Einstellmöglichkeit, um das zu ändern. Habe damals selber auch geflucht.
In SDAC braucht (und sollte) man ja nur mal kurz die Properties durchzuschauen, da findet man einiges, was einem die Arbeit erleichert, wie zB. die Möglichkeit, dass bei einem Insert mit einem IDENTITY dieser Wert von SDAC automatisch aktualisiert wird und ohne weiteres Zutun zB. im afterInsert-event schon zur Verfügung steht. Oder ein Autorefresh alle X Sekunden, oder.... und für die Oracle-Anhänger gibt es sogar die Property "SetEmptyStrToNull"

bye,
Helmut

[Bernhard Geyer]

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.

Solche "gutgemeinten" Defaults haben mich mit anderen DB-Kompos schon mal einige Zeit zur Fehlersuche gekostet. Vor allem dann wenn wie bei Oracle dann noch aus einem Leerstring ein NULL wird und damit Joins nicht mehr wie erwartet funktionieren ggrrrrrrr...

[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

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

[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ß

[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ß

[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

[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ß

[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]

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ß

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