Stange behaviour of Lazarus Trunk version

[Zvoni]

Has anyone thought about NOT using TDBLookupComboBox, but the NON-DB-Bound LuCB?
Maybe instead of trying to force the SQL to work properly, the issue could have been resolved already by filling up the Control "by hand"

[TRon]

The original reason why fields were cut at 255 char/1020 bytes is that somehow an string without size was found (which results in cutting the field). VARCHAR without length is cut in FPC while VARCHAR(25) works just fine. Maybe that should have been addressed.

Most probably, yes.

The fact that TEXT is translated to ftMemo isn't a big deal as long as VARCHAR and CAST is treated as ftString.

Forgive my ignorance but does that imply that if the patch would look more like that of the fix for ODBCConnection that this current issue could be solved (e.g. distinguish in VARCHAR type between ftString and ftmemo ) ?

Maybe instead of trying to force the SQL to work properly, the issue could have been resolved already by filling up the Control "by hand"

I think the current issue is more about behaviour that was changed with the fix (backwards compatibility) and not about the intention of the fix.

[Zvoni]

The fact that TEXT is translated to ftMemo isn't a big deal as long as VARCHAR and CAST is treated as ftString.

Eh? No.
CAST should be treated as the DataType it is being cast to.
And yes, CAST to CHAR/VARCHAR should be treated as ftString

Maybe instead of trying to force the SQL to work properly, the issue could have been resolved already by filling up the Control "by hand"

I think the current issue is more about behaviour that was changed with the fix (backwards compatibility) and not about the intention of the fix.

OK, agreed.

Maybe turn it around: Instead of fixing ftString at 255 bytes, fix it at MaxSmallInt if "Size" is missing.
Then "my" fix/patch could be removed

[rvk]

Has anyone thought about NOT using TDBLookupComboBox, but the NON-DB-Bound LuCB?
Maybe instead of trying to force the SQL to work properly, the issue could have been resolved already by filling up the Control "by hand"

The problem with the fix isn't contained to the lookupbox anymore.
TDataset.Locate also doesn't handle the ftMemo well (you can't use Locate with those fields).

The fact that TEXT is translated to ftMemo isn't a big deal as long as VARCHAR and CAST is treated as ftString.

Forgive my ignorance but does that imply that if the patch would look more like that of the fix for ODBCConnection that this current issue could be solved (e.g. distinguish in VARCHAR type between ftString and ftmemo ) ?

I'm not familiar with the fix of odbcconnection.

But FPC could first fix the VARCHAR without length. After that, the fix for virtual tables for which this fix was made, isn't needed anymore and those can revert back to ftString.

Eh? No.
CAST should be treated as the DataType it is being cast to.
And yes, CAST to CHAR/VARCHAR should be treated as ftString

True. And it will if the fix was reversed.
(After which the issue for cut field in virtual table can be re-investigated)

[TRon]

I'm not familiar with the fix of odbcconnection.

see here. It seems to address the same issue but for ODBC hence why I mentioned it in the other thread e.g. to indicate the need for a change is/was correct.

fwiw: you are far better/more versed with databases than I am so your suggestion might be a (far) better one than the fix for ODBC.

[rvk]

I'm not familiar with the fix of odbcconnection.

see here. It seems to address the same issue but for ODBC hence why I mentioned it in the other thread e.g. to indicate the need for a change is/was correct.

fwiw: you are far better/more versed with databases than I am so your suggestion might be a (far) better one than the fix for ODBC.

Yes, it's something similar (not exactly the same though).

Problem change is here
https://gitlab.com/freepascal.org/fpc/source/-/blob/main/packages/fcl-db/src/sqldb/sqlite/sqlite3conn.pp?ref_type=heads#L552

Cast to varchar is always stText from sqlite.
That line is added so it's now always a ftMemo.

The change was because in a virtual table the size for ftString couldn't be extracted.
That's in this line.
https://gitlab.com/freepascal.org/fpc/source/-/blob/main/packages/fcl-db/src/sqldb/sqlite/sqlite3conn.pp?ref_type=heads#L574

In that case 255 chars was used (which is cut to 1020 bytes).

Maybe it's better to just assume maxstring length if no size was given.
But because decltype is also empty for cast, there is no way to get to any possible length for VARCHAR given in the cast, is there?

[Zvoni]

In that case 255 chars was used (which is cut to 1020 bytes).

Maybe it's better to just assume maxstring length if no size was given.
But because decltype is also empty for cast, there is no way to get to any possible length for VARCHAR given in the cast, is there?

Not that i know of.
Maybe we should really go for Size1:=MaxSmallInt

Why was it set to 255 in the first place? Memory-Consumption some 20 years ago?

[marcov]

Marco meant that the change with showing (MEMO) was also made (merged back) in the fixes version. That's a version that's considered more stable than trunk.

I don't think there is a fix planned for this.

I think the problem is primarily on the tdbcombolookupbox side that can't handle memo, not in FPC changing some fields to memo.

[Zvoni]

Huh?
Is there something wrong with Sourceforge?
I'm getting a 404 for
https://lazarus-ccr.sourceforge.io/docs/lcl/dbctrls/tdblookupcombobox.html

An error has been encountered in accessing this page.

1. Server: lazarus-ccr.sourceforge.io
2. URL path: /docs/lcl/dbctrls/tdblookupcombobox.html
3. Error notes: NONE
4. Error type: 404
5. Request method: GET
6. Request query string: NONE
7. Time: 2024-06-11 11:15:56 UTC (1718104556)

[rvk]

I think the problem is primarily on the tdbcombolookupbox side that can't handle memo, not in FPC changing some fields to memo.

Nope. As you can see a few posts back, the problem now also extends to TDataset.Locate which can't handle ftMemo fields. How would you deal with that?

The real problem is that now calculated fields (i.e. CAST AS VARCHAR) is considered ftMemo.
That's just wrong.

[madref]

It's also not fixed in the fixed version of Lazarus

[jamie]

All this because of not being able to determine the string length?

What's wrong with the #0 at the end of the string as a length?

Last time I checked most DB engines were written in languages that used NUL char at the end of a string.


Or have I strayed off course again?

[dsiders]

Huh?
Is there something wrong with Sourceforge?
I'm getting a 404 for
https://lazarus-ccr.sourceforge.io/docs/lcl/dbctrls/tdblookupcombobox.html

An error has been encountered in accessing this page.

1. Server: lazarus-ccr.sourceforge.io
2. URL path: /docs/lcl/dbctrls/tdblookupcombobox.html
3. Error notes: NONE
4. Error type: 404
5. Request method: GET
6. Request query string: NONE
7. Time: 2024-06-11 11:15:56 UTC (1718104556)

Source Forge decided to truncate the hosting directory for the documentation. It has been restored as of now... until the next time they get spastic.

[madref]

I hope that some can resolve this strange behaviour so that I and my fellow coders don't have to jump hoops like we do now 

[Thaddy]

All this because of not being able to determine the string length?

What's wrong with the #0 at the end of the string as a length?

Last time I checked most DB engines were written in languages that used NUL char at the end of a string.


Or have I strayed off course again?

If it is really a pascal string the lenght is stored at negative offset, so no need to call strlen. It always ends with #0 or #00 depending on string type.