Hallo,

Ich habe ein paar Projekte in denen ich mittels der DevArt MyDAC-Komponenten auf eine MySQL-DB zugreife. (Charset ist UTF8)
Selbst in den kleineren werde ich beim compilieren von Warnungen erschlagen, die auf "problematische" String/Ansistring-Umwandlungen deuten. (Und damit werden natürlich echte Warnungen leicht übersehen)

z.B. bei sowas:

markieren

Delphi-Quellcode:

 
qrItemsPriceFormat.Value := Format('%.2f',[qrItemsItemPrice.Value]);

oder sowas:

markieren

Delphi-Quellcode:

 
s := 'Soll der Artikel "' + dmData.qrArticleArticleName.Value + '" wirklich gelöscht werden?';

Die Warnungen haben natürlich recht, TStringField.Value ist vom Typ ansistring und implizite casts können da zu problemen führen.
Um die Warnungen zu umgehen könnte ich natürlich jedesmal explizit casten oder mit TEncoding arbeiten, aber das ist mir zu umständlich und verringert die Lesbarkeit des Codes. Gibt es nicht ne einfachere Methode?

Lass mal die persistenten Felder neu erstellen? AFAIK gibts hier auch sowas wie TWideStringField.

Alternativ kannst du statt .Value auch .AsString schreiben.

Anstatt xxx.value schreibe ich das immer xxx.asstring, dann ist Ruhe.

Und selbst das mit dem Encoding ist nicht im Geringsten umständlich.

Du leitest dir entweder die Klassen ab und baust dir einfacher Property, worin das alles enthalten ist, oder du erweiterst die Klassen implizit über Class-Helper.


z.B. das was Emba in XE2 per Record-Methoden direkt in TRect und Co. integriert hat, hatte ich mir schon seit 2006 schon selbst gebstelt oder über über Record-Helper an fertige Records angehängt.

Vielen Dank für die Antworten.

Meine Lösung sieht noch etwas anders aus.
Die TMyConnection hat eine Option "UseUnicode".
Sobald die aktiviert ist, werden TWideStringField / TWideMemoField statt TStringField / TMemoField verwendet.
Dann musste ich noch einmal die Felder in meinen Querise löschen und wieder hinzufügen und schon war ich die ganzen Warnungen los.