> Jiri, what you said (change SQL_TEXT to SQL_VARYING) and what I show you
> (fixMetadata function) just fix this problem.
I wish. See below.
Also I have to investigate the 32766 or 32767 limit Dmitry Y. mentioned.
I suppose he's not lying. :) That would make it suck even more.
> Change it and forget. You'll always read SQL_VARYING and have the actual
> length in the first two bytes.
This is what I'm getting from the server. The field is CHAR(20) UTF8.
The length from metadata is 80. The memory dump where the pointer points
is:
{ 80, 0, 49, 50, 51, 52, 53, 54, 55, 56, 57, 48, 49, 50, 51, 52, 53, 54,
55, 56, 57, 48, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32,
32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32,
32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32,
32, 32, 32, 32, 32, 32, 32, 32, 32 }
Which clearly shows the first two bytes are reporting 80 as well. Fair
enough. Reading that buffer as UTF8 (or just looking at it, is basically
plain US-ASCII, nothing fancy) you get
"12345678901234567890____________________________________________________________"
(I replaced the spaces with visible character). It's clearly correct
string at the beginning and then 60(!) spaces. And that doesn't look
correct to me at all.
I think that's what Dimitry S. was pointing to.
With all that, unless I'm doing something wrong, I'd need to do some
trimming (or forgot about CHARs at all). The conversion to SQL_VARYING
gets me only so far.
> This change from SQL_TEXT->SQL_VARYING will not work only in some old
> versions (maybe firsts 2.1.x or 2.0.x).
Fine for me, as external engine needs 3.0 anyway.
--
Mgr. Jiří Činčura
https://www.tabsoverspaces.com/
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
