Recent

Author Topic: Stange behaviour of Lazarus Trunk version  (Read 7889 times)

Zvoni

  • Hero Member
  • *****
  • Posts: 2472
Re: Stange behaviour of Lazarus Trunk version
« Reply #75 on: June 11, 2024, 11:32:55 am »
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"
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad

TRon

  • Hero Member
  • *****
  • Posts: 2888
Re: Stange behaviour of Lazarus Trunk version
« Reply #76 on: June 11, 2024, 11:33:06 am »
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.

Quote
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.
« Last Edit: June 11, 2024, 11:35:32 am by TRon »

Zvoni

  • Hero Member
  • *****
  • Posts: 2472
Re: Stange behaviour of Lazarus Trunk version
« Reply #77 on: June 11, 2024, 11:35:39 am »
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

Quote
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
« Last Edit: June 11, 2024, 11:38:56 am by Zvoni »
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad

rvk

  • Hero Member
  • *****
  • Posts: 6276
Re: Stange behaviour of Lazarus Trunk version
« Reply #78 on: June 11, 2024, 11:39:15 am »
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).

Quote
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

  • Hero Member
  • *****
  • Posts: 2888
Re: Stange behaviour of Lazarus Trunk version
« Reply #79 on: June 11, 2024, 11:42:27 am »
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.

« Last Edit: June 11, 2024, 11:47:38 am by TRon »

rvk

  • Hero Member
  • *****
  • Posts: 6276
Re: Stange behaviour of Lazarus Trunk version
« Reply #80 on: June 11, 2024, 11:55:41 am »
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

  • Hero Member
  • *****
  • Posts: 2472
Re: Stange behaviour of Lazarus Trunk version
« Reply #81 on: June 11, 2024, 12:49:01 pm »
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?
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11652
  • FPC developer.
Re: Stange behaviour of Lazarus Trunk version
« Reply #82 on: June 11, 2024, 01:02:58 pm »
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

  • Hero Member
  • *****
  • Posts: 2472
Re: Stange behaviour of Lazarus Trunk version
« Reply #83 on: June 11, 2024, 01:17:43 pm »
Huh?
Is there something wrong with Sourceforge?
I'm getting a 404 for
https://lazarus-ccr.sourceforge.io/docs/lcl/dbctrls/tdblookupcombobox.html
Quote
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)
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad

rvk

  • Hero Member
  • *****
  • Posts: 6276
Re: Stange behaviour of Lazarus Trunk version
« Reply #84 on: June 11, 2024, 01:22:21 pm »
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.
« Last Edit: June 11, 2024, 01:23:52 pm by rvk »

madref

  • Hero Member
  • *****
  • Posts: 1028
  • ..... A day not Laughed is a day wasted !!
    • Nursing With Humour
Re: Stange behaviour of Lazarus Trunk version
« Reply #85 on: June 11, 2024, 10:38:50 pm »
It's also not fixed in the fixed version of Lazarus :(
You treat a disease, you win, you lose.
You treat a person and I guarantee you, you win, no matter the outcome.

Lazarus 3.99 (rev main_3_99-2145-g5d9f393aae) FPC 3.3.1 x86_64-darwin-cocoa
Mac OS X Sonoma 14.5

jamie

  • Hero Member
  • *****
  • Posts: 6376
Re: Stange behaviour of Lazarus Trunk version
« Reply #86 on: June 12, 2024, 12:08:34 am »
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?

The only true wisdom is knowing you know nothing

dsiders

  • Hero Member
  • *****
  • Posts: 1178
Re: Stange behaviour of Lazarus Trunk version
« Reply #87 on: June 12, 2024, 03:54:44 am »
Huh?
Is there something wrong with Sourceforge?
I'm getting a 404 for
https://lazarus-ccr.sourceforge.io/docs/lcl/dbctrls/tdblookupcombobox.html
Quote
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.
Preview Lazarus 3.99 documentation at: https://dsiders.gitlab.io/lazdocsnext

madref

  • Hero Member
  • *****
  • Posts: 1028
  • ..... A day not Laughed is a day wasted !!
    • Nursing With Humour
Re: Stange behaviour of Lazarus Trunk version
« Reply #88 on: June 13, 2024, 01:00:27 am »
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  ;)
You treat a disease, you win, you lose.
You treat a person and I guarantee you, you win, no matter the outcome.

Lazarus 3.99 (rev main_3_99-2145-g5d9f393aae) FPC 3.3.1 x86_64-darwin-cocoa
Mac OS X Sonoma 14.5

Thaddy

  • Hero Member
  • *****
  • Posts: 15176
  • Censorship about opinions does not belong here.
Re: Stange behaviour of Lazarus Trunk version
« Reply #89 on: June 13, 2024, 03:23:13 pm »
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.
Of course the national anthem of the U.S.A. was written by Jimi Hendrix, didn't you know that?

 

TinyPortal © 2005-2018