Lazarus crashes at "Post" after update from 1.8.2 to 2.0.10 and 2.2

[xenon1]

I just want to report: After updating Lazarus from 1.8.2 to 2.0.10 (and again after I updated to 2.2, hoping the problem would go away), it regularly crashed at the database command "Post" when posting a string. (Commands: Edit; FieldByName('xxx').AsString := 'xxxx'; Post).

It took me two days to figure out why: Lazarus had given the field length ("Size") as something like 1000 or even 1024, as I finally found in the Object Inspector, although the field length of the database field (firebird) was only 255 [varchar(255)]. When I set the field length in the Object Inspector to the right value (Size: 255) everything went fine.

My operationg system during this problem: MX Linus 21.1., based on Debian 11 (bullseye).

I was surprised that nobody had reported a similar problem on the Internet, as Lazarus 2.0.10 has been released some time ago. I cannot imagine to be the first person to have experienced this. Whatever, I post this here so that someone else might not have to search days for a solution.

I do not know if this counts as an official bug, and I would not know where to report it anyway.

[MarkMLl]

I do not know if this counts as an official bug, and I would not know where to report it anyway.

There's a link to the bugtracker at the left of the forum page, i.e. somewhere

<===== OVER THERE :-)

MarkMLl

[af0815]

I do not know if this counts as an official bug, and I would not know where to report it anyway.

And it is good to have a program/demo code to show this bug. It make it easier for the developer to analyse the bug. Reports with demo code often fixed very fast.

[bum_bum]

It took me two days to figure out why: Lazarus had given the field length ("Size") as something like 1000 or even 1024, as I finally found in the Object Inspector, although the field length of the database field (firebird) was only 255 [varchar(255)]. When I set the field length in the Object Inspector to the right value (Size: 255) everything went fine.

Maybe the problem is related to the encoding? In UNICODE, a character can take 4 bytes, then 255 characters will be 1020 bytes long.

[Thaddy]

How much is 256 X 4 ?
.... It is NOT 1020, but

1024

But you are correct that you advise is to reserve 4 per byte in all cases except strict Ansi or shortstring.

My other advice would be to do everything on a network in BYTES and not any string type.

[bum_bum]

How much is 256 X 4 ?
.... It is NOT 1020, but

1024

In the original message 255, not 256. Look carefully...

[Thaddy]

the byte range is 0..255 which makes 256. And that is what you need especially when streaming data.
Programmers count from zero.
Really silly. I thought BASIC programmers had by now disappeared. (except from me and a couple of even older archaeological finds    )

If you want to stream, plz preserve ALL data and do not throw away anything (like 4 bits per package, which will screw you up).
With most - but not all - CPU's you want to stick to a power of two, which is usual CPU register width or an exact fraction of it.
1024 is a power of two, 1020 is error.

For educational purposes: https://en.wikipedia.org/wiki/Power_of_two
Mind the value of n....

[MarkMLl]

the byte range is 0..255 which makes 256. And that is what you need especially when streaming data.
Programmers count from zero.

SQL doesn't: varchar(255) has a maximum length of 255.

I thought people who assumed that all languages behaved like C had by now disappeared: particularly in this community.

MarkMLl

[korba812]

the byte range is 0..255 which makes 256. And that is what you need especially when streaming data.
Programmers count from zero.
Really silly. I thought BASIC programmers had by now disappeared. (except from me and a couple of even older archaeological finds    )

If you want to stream, plz preserve ALL data and do not throw away anything (like 4 bits per package, which will screw you up).
With most - but not all - CPU's you want to stick to a power of two, which is usual CPU register width or an exact fraction of it.
1024 is a power of two, 1020 is error.

For educational purposes: https://en.wikipedia.org/wiki/Power_of_two
Mind the value of n....

🤦

[tonyw]

I just want to report: After updating Lazarus from 1.8.2 to 2.0.10 (and again after I updated to 2.2, hoping the problem would go away), it regularly crashed at the database command "Post" when posting a string. (Commands: Edit; FieldByName('xxx').AsString := 'xxxx'; Post).

It took me two days to figure out why: Lazarus had given the field length ("Size") as something like 1000 or even 1024, as I finally found in the Object Inspector, although the field length of the database field (firebird) was only 255 [varchar(255)]. When I set the field length in the Object Inspector to the right value (Size: 255) everything went fine.
<snip>

I'm trying to understand what went wrong here. Firstly, you haven't said which Firebird database driver you are using. Also, have you used to Fields Editor to add the fields to the form, or are you relying on the fields to be dynamically created each time you open the dataset? You have said that you are using "FieldByName" and so I will assume the latter.

In general, all database drivers should  work the same.

When you open a dataset, the FieldDefs collection should be automatically created by the InternalInitFieldDefs method. In IBX, InternalInitFieldDefs runs a query on the database and creates the fielddefs, including the Field Size, from the metadata returned by Firebird. It should be a proper reflection of the database schema - but will also depend upon the connection character set for VarChar. If the field is UTF8 encoded or the connection character set is UTF8 then the field size is four times the character size in order to cope with a maximum length UTF8 string.

The odd thing is that you said the crash occurred when an updated record was posted and that you needed to reduce the field size to make it work.This does not really add up.

Alternatively, if you had used the fields editor, then the field size is saved in the form. When you upgraded, the form would be unchanged and the field size remains unchanged. Maybe, in the previous version you had used a connection character set of UTF8 and hence the long field size and then after upgrade a single byte character set was used (e.g. ANSI). That would explain your problem.