rutsche gerade in eine weiteres Problem beim Portieren einer Anwendung auf LINUX

markieren

Delphi-Quellcode:

     aString : String[25];

was geht denn hier schief ? Error E2029 ';' expected but '[' found

ShortStrings sind doch schon seit Ewigkeiten deprecated. Es ist also nicht verwunderlich, daß die unter den NextGen Compilern nicht mehr unterstützt werden.

Vor allem da es den ShortString ausschließlich mit ANSI gibt, was dort sowieso fehlt.

https://www.delphipraxis.net/196723-...erfuegbar.html


Lösung: statisches Array oder ein Record, wenn es wie ein Record/einfacher Typ (ohne Pointer) genutzt wird.

wenn z.b. length(astring) genutzt wird, dann muß man größere Umbauten vornehmen.
Ansonsten

markieren

Delphi-Quellcode:

tshortstring=packed record
                Long:byte;
                text:array of {Byte oder 8Bit-Char}
             end;

Aber beachten, das ist nur ein Datencontainer!
Die meisten Funktionen werden wahrscheinlich mit einem Fehler aussteigen.

Gruß
K-H

Zitat von p80286:

Aber beachten, das ist nur ein Datencontainer!

Den man aber ja mit ein paar Methoden passend erweitern könnte. Aber mal ehrlich, wenn schon Umbau, warum dann nicht gleich richtig?

wir haben dann in der MSSQL-Datenbank-Felder hierfür definiert wie

 ......, AName varchar(25) NULL, ..... was mache ich denn hier wenn ich die SQL scripte nicht auch noch gleichzeitig anfassen will am besten ?

Wie "versorgst" Du denn die Scripte mit den entsprechenden Werten?

Per qry.ParamByName('Feldname').AsString?
Per qry.FieldByName('Feldname').AsString?

Oder ...?

Du könntest bei der Zuweisung eine Längenprüfung machen.

Bei den Datenbankkomponenten kann man doch (eigentlich) bei 'ner geöffneten Abfrage die Feldinformationen bekommen. Diese kann man dann für eine Längenprüfung bei einer Wertzuweiseung heranziehen.

Ggfls. macht man beim Programmstart mal eine entsprechende Abfrage pro Tabelle ... und merkt sich die Felddefinitionen. Mit denen kann man dann 'ne Plausibilitätsprüfung / Längenprüfung realisieren. Eventuell gelingt es ja sie so dynamisch zu machen, dass bei Änderungen des Datentypes, der Länge von VarChar-Feldern ... im Programm diese Änderungen automatisch erkannt werden und berücksichtigt werden (ohne nochmal an den Programmquelltext zu müssen).

Oder die passenden Infos aus dem INFORMATION_SCHEMA auslesen und dann bei der Wertezuweisung berücksichtigen ...

Zeig' uns doch mal einen Auszug aus Deinem bisherigen Quelltext, bei dem das Problem momentan konkret auftritt. Eventuell kann man dann etwas zielgerichteter weiterdenken und Hilfestellung geben.

Zitat von bernhard_LA:

was mache ich denn hier wenn ich die SQL scripte nicht auch noch gleichzeitig anfassen will am besten ?

Ein string kann in der Regel die Daten aller varchar(nn) Konstrukte aufnehmen (sogar auch nvarchar!). Das hat sogar den Vorteil, daß bei einer Änderung in der Datenbank der Delphi-Code nicht auch noch geändert werden muss. Dafür bietet FireDAC auch eine entsprechende Option an, die statische String-Felder zur Laufzeit in der Größe an die Datenbank anpasst.

Das Problem ist wohl nicht, dass ein String "zu kurz" sein könnte, sondern eher, dass der String "mehr" enthält, als das Datenbankfeld aufnehmen kann.

Man muss halt schauen, welche Möglichkeiten einem die Datenbankkomponenten bieten, hier auf Konflikte zu reagieren bzw. erst garkeine Konflikte aufkommen zu lassen.

Zitat von p80286:

wenn z.b. length(astring) genutzt wird, dann muß man größere Umbauten vornehmen.
Ansonsten

markieren

Delphi-Quellcode:

tshortstring=packed record
                Long:byte;
                text:array of {Byte oder 8Bit-Char}
             end;

Aber beachten, das ist nur ein Datencontainer!
Die meisten Funktionen werden wahrscheinlich mit einem Fehler aussteigen.

Gruß
K-H

ShortString ist ein statisches Array!
Bei dir ist "text" ein Pointer und da muß man eventuell so Einiges beachten. (leider kann man mit den Generics nicht de größe dieses Arrays definieren, womit sich damit nichts dynamisches für Length 1..255 erzeugen lässt)