![]() |
Datenbank: access • Version: ??? • Zugriff über: jetengine
Umlaute bei D7 ADO/Access
Ich bin neu hier - deshalb erst mal ein Hallo an das Forum.
Ganz unbedarft in Delphi bin ich nicht, früher war ich mal unter meinem Usernamen cckLoud im Delphitreff aktiv, vielleicht erinnert sich ja jemand ... Aber nun zum Problem! Ich habe so eine kleine Branchensoftware (ca. 540000 loc) in D7 geschrieben. Die läuft auch einwandfrei, jedenfalls bis gestern ein neuer Kunde das Produkt getestet hat - auf einem Surface-Rechner mit WIN 10. Das Problem ist, dass 1. alle Umlaute in den Captions (Buttons, Labels) so UTF8-Mässig angezeigt werden (die fix über die IDE vorgegeben sind) 2. wenn ich per ADO/SQL auf die DB zugreifen will, werden Teile des SQL-Strings entsprechend obiger Weise verhachstückt. Da gibt es beim Insert into eine Fehlermeldung "unbekannter Feldname 'strai??e'" wobei das "ai??" für seltsame Zeichen steht, die ich (??) nicht auf der Tastatur habe. in dem SQL-String steht hier eindeutig "Straße" 3. wenn ich Strings aus der Datenbank (ACCESS/JetEngine über ADO)und ausgebe (zB in ein Edit-Feld), dann passiert das Selbe wie bei den Captions Das ganze hat zweifellos was mit UTF zu tun. Nur bei allen anderen Kunden passiert das nicht. Wie kann zB das mit der IDE als Ansi abgelegt (und als Resource gespeichert). Ich denke, das hat mit einer Win-Einstellung zu tun, die bei Dateizugriffen einen UTF-Wandler zwischenschaltet. Ich habe mich jetzt seit 4 Tagen im INet rumgetrieben, aber nix brauchbares gefunden. Vielleicht kennt ja jemand von euch das Problem und weiss Abhilfe? |
AW: Umlaute bei D7 ADO/Access
Wenn du unter D7 mit ADO/dbGo darauf zugreifst dürfte da nix von Windows dazwischen funken.
Oder nutzt du hier dbExpress? |
AW: Umlaute bei D7 ADO/Access
Nein, ich nutze ADO. Und dass da Win zwischenfunkt, hätte ich auch nicht gedacht.
Aber danach sieht es halt aus. Ich würde das bei 2 und 3 im Bereich des COM-Marshallers ansiedeln, da ich korrekte SQL abliefere, und bei der JET-Enging offensichtlich Müll ankommt. Und auch bei 1: soweit mir bekannt, speichert die Maskendefinitionen als Resourcen, und ds Lesen derselben erfolgt über ein WIN-Funktion... Wie sonst könnte auch in D7 "intern" UTFirgendwas zun Zug kommen? |
AW: Umlaute bei D7 ADO/Access
Liste der Anhänge anzeigen (Anzahl: 1)
Es gibt in Windows 10 mittlerweile eine nette kleine gut versteckte Checkbox in den Regions-Einstellungen ("Beta: Unicode UTF-8 Unterstützung...") die wahrscheinlich nicht ganz ohne Hintergrund mit "Beta" bezeichnet ist. Prüfe mal ob diese Option bei deinem Kunden aktiv ist. Abschalten sollte die Lösung für dein Problem sein.
|
AW: Umlaute bei D7 ADO/Access
Danke für den Tip, hört sich gut an. Werde ich auprobieren (lassen), geht aber natürlich heute nicht - Wochenende!
Ich geb aber Bescheid! |
AW: Umlaute bei D7 ADO/Access
Zitat:
hast du evtl. diese im Einsatz? |
AW: Umlaute bei D7 ADO/Access
Zitat:
Das verursacht doch mehr Problem als es löst? |
AW: Umlaute bei D7 ADO/Access
Weil es abertausende Anwendungen gibt, die mit Ansi laufen?
Klar, man könnte natürlich auf zB Rio umsteigen, aber so einfach ist das nicht, wenn das auch immer wieder kolportiert wird. Auch wir haben uns Rio besorgt und die Umstellung war auch tatsächlich in 3 Tagen durch. Sollte man meinen, denn im Detail war es nicht so, wie man es erwartete - zB bei Grids gibt es massive Probleme, die werden nicht korrekt dargestellt und müssen fast alle nachgearbeitet werden. Und das dauert, schliesslich hat das Programm so ungefähr 500 Masken und Frames. Und dann muss man ausgiebig testen, sonst rassten die Kunden aus. Und die laufenden Weiterentwicklungen nicht vergessen! Also bei uns dauert das noch mindestens 3/4 Jahre, bis wie das Programm launchen können. Und so lange sind wir froh darüber, dass es einen Kompatibilitätsmodus gibt, auch wenn die IDE des Öfteren mal win10 freezed! |
AW: Umlaute bei D7 ADO/Access
Zitat:
![]() Damit wäre es dann möglich den Wert abzufragen und wenn er gesetzt sein sollte, den Anwender darauf hinzuweisen, dass mit dieser Einstellung ein korrekter Programmbetrieb nicht möglich ist. (Sofern sich herausstellen sollte, dass dies die Fehlerursache ist.) |
AW: Umlaute bei D7 ADO/Access
Zitat:
Zitat:
Wir konnten auch erst zu XE6-Zeiten umstellen und sind mit den nächsten Sprung bei 10.2. Im nachhinein betrachtet hätte man die Umstellung noch früher durchziehen müssen um nach der abkündigung der Win9x/ME-Schiene nicht mit einer Unproduktiveren IDE arbeiten zu müssen. Zitat:
Bei uns war es "einfacher", da wir schon seit Jahren (mit D6) Unicode unterstütz hatten und vieles mit einem eigenen String-Typ (MyType = WideString) gearbeitet hatten, so das wir schon viele Stellen "entschärft" hatten. Auch hat unsere Bibliothek (ElPack) uns hier nur realtive "einfache" Hürden beim Update auf aktueller XE6-Version steine in den Weg gelegt. Zitat:
Zitat:
Zitat:
Das die IDE-Freezed kann passieren. Aber wenn das OS auch mit eingefrohren wird liegt noch woanders ein Problem vor. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:40 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz