Migration BDE zu ADO Problem mit Zeichensätzen

[tbachert]

Hallo zusammen


Ich beschäftige mich gerade damit, eine größere Anwendung von der Nutzung der BDE auf ADO umzustellen.

Die Anwendung kann mit DB2, Oracle, MSSQL und einigen anderen Datenbanken umgehen.
Für SQL Server 2005 ist nun die Umstellung auf ADO nötig.

vorhandene Datenbanken / Daten sollen hierbei natürlich weiter genutzt werden.

Innerhalb der Datenbank ist ein Zeichensatz eingestellt, der zu DOS kompatibel ist, da auch noch DOS Clients zum Einsatz kommen.

Nun zum eigentlichen Problem:

Bei der BDE Verbindung wird über den Parameter LANGDRIVER ein Zeichensatz eingestellt. Damit kommen die Datensätze richtig an (oder werden richtig konvertiert). Das Darstellen von Umlauten, etc. ist kein Problem.

Bei der ADO Verbindung habe ich keine Einstellung für den Zeichensatz wie LANGDRIVER o.ä. gefunden.
Deshalb sind nun bei der Verwendung von ADO statt z.B. äöüß nur seltsame Zeichen an diesen Stellen, da wohl die Umlaute usw. in dem Zeichensatz an anderer Stelle liegen.

Meine Frage ist nun, gibt es eine Möglichkeit einer ADO Verbindung ähnlich wie mit dem Parameter LANGDRIVER bei BDE einen Zeichensatz mitzugeben?

Oder wie könnte man das sonst lösen?

Vielen Dank und Gruß

Timo Bachert

[Bernhard Geyer]

1, Nur für den MS SQL-Server ist ADO die zu empfehlende Zugriffsschicht. Bei allen anderen Datenbanken geht man über deren native Schnittstelle. Für Oracle sind z.B. die Kompos von Core labs und Allround Automation einen Blick wert.
Die Datenbank-Unterschide kapselt man am Besten z.B. durch die Verwendung des Bridge-Pattern

2, Dein Zeichensatzproblem schein eher zu sein das die Daten "zerschossen" in die Datenbank gelangen. Wie schauen die Daten aus wenn sie z.B. per Enterprise Manager angeschaut werden. Hier wirst Du vermutlich auf Client-Ebene einen Konvertierung einbauen müssen da ADO sowas "veraltetes" nicht mehr vorsieht und eigentlich mit Unicode arbeitet. Kann man nicht die DOS-Clients (wirklich DOS oder Consolen-Programme) nicht ablösen bevor man hier große Umbauarbeiten und Wochen investieren muß bloß um solche legacy-Anwendungen noch am laufen zu halten? Evtl. ist es auch nur nötig die Daten "richtig" per Batch-Lauf zu konvertieren und für die Altanwendungen andere LANGDRIVER-Einstellungen zu probieren.

[tbachert]

Es geht letzten Endes darum, dass die Software bei mehr als 500 Kunden im Einsatz ist.

Von daher kann ich nicht einfach eine Batch Konvertierung in der Datenbank vornehmen.

Die Clients sind echte Dos Clients auf 486er Terminals.

Wenn ich den entsprechenden Datensatz in Oracle SQL Plus abrufe sieht es so aus:
l*schbar wobei der * ein auf dem Kopf stehendes Fragezeichen sein soll.

Es wird mir wohl nichts anderes übrig bleiben, als nach dem Ausführen des SQL Statements vor der Anzeige die Daten zu konvertieren.
Gibt es dafür fertige VCL Funktionen?

Was genau bewirkt eigentlich der LANGDRIVER bei der BDE?

Gruß

[Bernhard Geyer]

Zitat:

Zitat von tbachert

Wenn ich den entsprechenden Datensatz in Oracle SQL Plus abrufe sieht es so aus:
l*schbar wobei der * ein auf dem Kopf stehendes Fragezeichen sein soll.

Bei Oracle mußt du mit der Umgebungsvariable NLS_LANG herumspielen um eine passende zu finden. Eine Liste der Möglichen Werte muß du dir selbst "ergooglen" (Selbst verwenden wir nur AMERICAN_AMERICA.UTF8). Diese kann z.B. beim Programmstart mit SetEnvironmentVariable lokal für dein Programm gesetzt werden.
Nachkonvertierung auf Client-Ebene ist nicht möglich da die Daten schon irreversible geändert wurden

[tbachert]

Danke, damit bin ich näher an der Lösung des Problems dran. NLS_LANG beeinflusst auch die Anzeige der Daten in der Applikation. Jetzt muss ich nur noch den richtigen Wert dafür finden.

Mit Microsoft SQL Server geht es sowieso richtig!

Danke und Gruß