2015 era sqllite app doesn't display field.

[marcov]

I've an 2015-2017 era sqldb-with-sqllite app that is for some personal administration. I had to update it, and saw that a field wasn't showing anymore. (with the same original DLL)

The field is ftfixedchar with size 128 and precision -1, and it is a simple query  (select * from tablename).  Any idea what that could be? something changed in the handling of string types?

[paweld]

You didn't mention which version of FPC you are using. But if it's trunk, 3.2-fixes, or 3.2.4rc1, the cause may be the patch from issue : https://gitlab.com/freepascal.org/fpc/source/-/issues/40686
The symptom is the field type set as ftMemo.

[rvk]

Any idea what that could be? something changed in the handling of string types?

Yes. Something has changed.
TEXT fields are now treated as ftMemo as in the past they were treated as ftString.

I think this was a wrong decision but it was done.

It would have been better to fix the FTS-Tables issue instead of generally change this for all tables.

[marcov]

fpc trunk/lazarus trunk, I tried setting the field to ftmemo, ftstring or ftfixedchar, and it doesn't display values in the grid either way.

[PascalDragon]

If I remember correctly then you need to set some option in the grid that allows it to display memo fields (dgDisplayMemoText in Options).

[marcov]

I investigated it a bit further, and no that is not it. I standard have the ongettext assigned to handle that.

The memo fields display fine, it is the TStringfield fields that fail.

[cdbc]

Hi

I standard have the ongettext assigned to handle that.

In that case, I'd suggest you read the field-value 'AsBytes' and convert to string yourself, in your handler...
Regards Benny

[marcov]

Hmm:

Maybe related to:

https://gitlab.com/freepascal.org/fpc/source/-/commit/f0e34e8fabafd121ee2a7e4f6e3f005727a271f7

 Map text field on ftMemo, since string has limited length. Fixes issue #40686

[Thaddy]

That fix has also caused other problems, namely the other way around: simple dbedit fields and the likes were accepting ftString, which you have to adapt to ftMemo.
Although the fix is logical, it is a breaking fix.
(Likely you ran into that)

[marcov]

I now confirmed this was the problem. It was a bit confusing, since the query editor of Lazarus still adds a TStringfield. I really had to manually add a field as ftmemo.

[marcov]

Worse, the linked TDBEdit still show (MEMO) and that doesn't have a property to display like dbgrid has.

[marcov]

Yes, Thaddy, I ran into that.

I asked Michael about it, and now there is at least some info about it:

https://wiki.freepascal.org/User_Changes_Trunk#TSQLite3Connection_string_fields

[rvk]

Yes, Thaddy, I ran into that.

I asked Michael about it, and now there is at least some info about it:

https://wiki.freepascal.org/User_Changes_Trunk#TSQLite3Connection_string_fields

I remember that the following was only true for some virtual tables. Not for normal tables.

TStringField size is limited to 8k, leading to loss of data if the field is longer (e.g. memo).

TStringField is definitely not limited to 8k.
O, apparently it is. But it's was not the original reason for the change to memo.

According to the source code this change was only implemented because of some limitations in FTS tables. I've always found this a wrong fix. They could have checked the table type and only implemented this for FTS, and not for other tables.

https://forum.lazarus.freepascal.org/index.php/topic,67472.msg519366.html#msg519366

[madref]

I investigated it a bit further, and no that is not it. I standard have the ongettext assigned to handle that.

The memo fields display fine, it is the TStringfield fields that fail.

Had the same problem back then.
I did this:

Code: Pascal  [Select][+][-]

1. procedure TForm_Wedstrijd_Informatie.DBMemoGetText(Sender: TField; var aText: string; DisplayText: Boolean);
2. begin
3.   aText := Sender.AsString;
4. end;     // DBMemoGetText
5.