EgonHugeist wrote:Sorry for my absence.. Busy currently.
It isn't wrong, the more it WAS wrong before 7.2.
As Michal did alredy wrote SQLite has a maximum of 2147483647 Characters but TString/WideStringField has a Maximum of 8KB. So the Columns won't fit and a unwanted trunkation happens. 7.12 and older did use 255 Chars by defult for string fields with undeclared Maximum lengths.
We had loads of bugreports for trunkated fields in the past for SQLite and PostgresSQL. So i changed this behavior as it should be right.
I left a compatibility option to have old behavior:
Add:
Code: Select all
TZConnection.Properties['Undefined_Varchar_AsString_Length'] := 255; //or your expected string field size
To your code before open your connection. Than you're a lucky man again.
Hello,
first of all, no need to be sorry, I develop software as well and know pretty much how busy our days generally are.
Much more for you, as you also code for a large and free project like ZEOS and of course that takes away even more time! My /hat to you!
Regarding the VARCHAR topic: I totally see your point and the logic behind it.
I have some points to bring on the table as well: all what's excellent technically and logic wise sometimes "encounters" reality and adjustments (like the one you suggested) need to be done.
In particular, Delphi visual controls have fairly poor support for Memos. Therefore I totally agree that a true memo field (TEXT for SQL) should be treated as such.
On the contrary, VARCHAR is defined as "character varying" and
looking at some quite influential source (Microsoft) they indeed span from 1 to 8000 bytes (like Delphi, coincidence?
).
I have always
personally been with the idea that a "normal" VARCHAR should be a string spanning from 0 to 255 bytes, if somebody else thinks that he should define a VARCHAR field to really store 3 petabytes of data, then I believe they are more distant from a good definition than me who love to stick to "old times" numbers.
Therefore it's way more unrealistic to expect to exceed 8k for a field type *that the industry* just does not use for that, than what I expect instead: to have Delphi render textual information of (VAR)CHAR fields in a consistent way and at the best possible way: that is not by just showing "TWideMemo". Even for an end user point of view, what do they think when they encounter "WideMemo" in a TEdit? "Wide whaaaat?".
Therefore I believe the "wrong" 7.1.2 approach is actually more useful in practice and for the majority of applications than the other way around. If someone truly complains because he wants to use a VARCHAR and not the appropriate TEXT field for storing large amounts of data, then it's them who are just not observing long time good practices and long time industry standards. Not the other way around.
Anyway the concept I'd like to express is this:
Please have this "compatibility option" be something that is sure to stay in, and maybe promote it into "feature". Because there's loads and loads of code relying on this: VARCHARs acting actually as VARCHARs. Calling it "compatibility option" sounds like you plan to phase it out / deprecate it sooner or later.
Please don't deprecate it, there's long time loyal users of your library who truly rely on it!
