Der Versuch, eine alte Anwendung auf einer frischen Delphi 7 Installation zu erstellen, brachte sofort beim Einbinden der Unit SqlExpr eine Fehlermeldung:
Unit SqlExpr wurde mit einer unterschiedlichen Version von SqlConst.SNOERROR compiliert
Leider haben mir der Tipp auf Delphipraxis nur bedingt weitergeholfen. Dazu soll folgender Code:
SNOERROR ='';
SWARNING ='';
SCONNECTIONFAILED ='';
SDRIVERINITFAILED ='';
SOPTLOCKFAILED ='';
SINVALIDREF ='';
SNOTABLE ='';
SDBXError ='';
SNODATA ='';
SSQLERROR ='';
SSQLServerError''; |
SNOERROR ='';
SWARNING ='';
SCONNECTIONFAILED ='';
SDRIVERINITFAILED ='';
SOPTLOCKFAILED ='';
SINVALIDREF ='';
SNOTABLE ='';
SDBXError ='';
SNODATA ='';
SSQLERROR ='';
SSQLServerError'';
in der SqlConst.pas im Source\VCL Ordner eingefügt werden und das ganze erzeugt und nach {Delphi}\Lib und {Delphi}\Lib\Debug verteilt werden. Wie man diese Unit aber erzeugt, stand leider nicht dabei und es ist mir auch nicht gelungen, den Code habe ich trotzdem eingefügt, da diese pas-Datei im Suchpfad ist.
In der Entwickler Ecke habe ich dann den nächsten Tipp gefunden:
Das nächste Problem scheint DBExpress zu sein, einige Projekte konnten nicht kompiliert werden, da SqlExpr.dcu mit einer anderen Version kompiliert wurde. Den Fehler konnte ich mittlerweile beheben, das Update hat im Verzeichnis $(DELPHI)\lib\ eine Datei SqlConst.dcu.de angelegt. Ich habe die Datei SqlConst.dcu dann nach SqlConst.dcu.org umbenannt und SqlConst.dcu.de nach SqlConst.dcu. Das gleiche auch nochmal im Verzeichnis $(DELPHI)/lib/debug.
Nachdem ich auch diese Umbenennung durchgeführt habe, klappte es wieder wunderbar. Der Fehler scheint übrigens irgendwie mit der deutschen Lokalisierung vom ServicePack 1 für Delphi 7 im Zusammenhang zu stehen.
Vor kurzem hatten wir auf einem neuen Windows 7 Rechner das Problem, dass die Regionaleinstellungen in der Anwendung nach EN-en aussahen, obwohl DE-de aktiviert war. Andere Windows 7 Rechner zeigten die Probleme nicht. Nach einiger Suche habe ich in einem Forum zwei mögliche Workaround ausmachen können:
1) Man schaltet die Ländereinstellungen auf irgendwas anderes, und dann wieder zurück auf die Wunschsprache.
2) Man fügt in sein Delphi Projekt folgende Unit ein und trägt sie in irgendeiner uses ein.
unit Win7;
interface
uses
SysUtils, Windows;
implementation
initialization
SetThreadLocale(LOCALE_USER_DEFAULT);
GetFormatSettings;
end. |
unit Win7;
interface
uses
SysUtils, Windows;
implementation
initialization
SetThreadLocale(LOCALE_USER_DEFAULT);
GetFormatSettings;
end.
Speziell nach Sichtung dieser zwei Zeilen bleibt aber die Frage zurück, ob das ein Problem von Windows 7 oder ein Problem von alten Win32 Anwendungen ist, die sich vielleicht unbewußt nicht an die Vorgaben von Microsoft halten.
Windows 64 Bit setzt sich in Zeiten fallender RAM-Preise immer mehr durch, als Vista64. Bei dem Zugriff auf die Registry stolpert man dabei aber über ungeahnte Probleme.
32Bit Programme legen Ihre Einträge nämlich nicht in der normalen Registry ab, sondern im Unterschlüssel Wow6432Node (wird von Windows umgeleitet):
Was bedeutet das für eigene Programme:
Möchte man von einem 64-Bit Programm aus auf Einstellungen eines 32-Bit Programms zugreifen, ist der Unterschlüssel Wow6432Node zu öffnen. Will man von einem 32-Bit Programm Einstellungen eines 64-Bit Programms auslesen, so steht man vor einem Problem. Will man auf die 64-Bit Schlüssel zugreifen, so muss man die Registry mit speziellen Parametern öffnen. Für Delphi findet man eine Lösung in Delphi-PRAXIS. Für .NET ist die Sache erstaunlicherweise komplizierter.
