CORRECTION: This only affects char(n) due to TrimRight(). Use varchar() as a workaround.
UPDATE1: changed #11 to #17 (it is 11 hex)
UPDATE2: added step 2.5
UPDATE3: #0 also truncates, but #1 doesn't truncate
UPDATE4: database confirmed to have non-truncated data, and works fine with non-Zeoslib program using fbclient20.dll (EMS Database Manager Lite) -- but programs using Zeoslib truncates field value
UPDATE5: changing charset to NONE for the field didn't fix this on a database created with WIN-1252 charset. But, recreating a test database with charset NONE and field charset NONE seems to avoid #17 truncation.
To reproduce in Delphi 2007:
1. create string containing #17
var binstr:AnsiString;
binstr = 'Hello' + #17 + 'World';
2. save to Firebird 2.0.3 database
2.5. CLOSE THE DATABASE! And reconnect. Otherwise, things look fine in DBGrid, etc. before you disconnect. Exit Delphi just to make sure.
3. use ZQuery with "select * from tablename;"
4. ZQuery.FieldByName('hash').Text is truncated at #17 char
ZQuery.FieldByName('hash').AsString is also truncated at #17 char
ZQuery.FieldByName('hash').Value is also truncated at #17 char
5. Zeoslib does not truncate when writing, but appears to truncate on reading from database if char/varchar field values contain #17 or #0.
Basically, I'm storing a binary hash into a 20 character field (charset OCTETS).
If the hash contains a #17 character, it gets truncated at that character.
I tested using Delphi 2007 and Firebird 2.03 embedded.
BUG? 6.6.2-RC: ZQuery.FieldByName(...).* truncates at #17
Moderators: gto, cipto_kh, EgonHugeist
BUG? 6.6.2-RC: ZQuery.FieldByName(...).* truncates at #17
Last edited by fx on 19.01.2008, 21:52, edited 7 times in total.
I am using charset OCTETS which is the recommended charset for strings containing binary data like sha1 hash, etc. I will try with your settings.cipto_kh wrote:I try using ZeosDBO 6.6.2-rc, Delphi 7, Firebird 2.0.3 SuperServer, charset: None.
There is no problem, everything save well, are you use special charset or UTF8?
IMPORTANT: The problem appears only after disconnecting and reconnecting to the database. Before disconnecting, everything in DBGrid looks fine and nothing is truncated. But after reconnecting, the same data is truncated visually in DBGrid and also from ZQuery.FieldByName().AsString, etc.
I confirmed the data is not truncated in the database, because it shows up fine using EMS Database Manager for Firebird. Also confirmed by trying to insert record with same value and got contraint error as expected.
Since the database contains non-trundated data and it is not truncated by non-Zeoslib program using the same fbclient20.dll, I am guessing this problem is Zeoslib.
- mdaems
- Zeos Project Manager
- Posts: 2766
- Joined: 20.09.2005, 15:28
- Location: Brussels, Belgium
- Contact:
cipto_kh, fx,
Please don't forget to log this in the bug tracker. We all know how quickly this kind of reports sinks down the forum... Unless you immediately find the solution, of course.
fx,
Do you have a small program inserting the data, closing the connection and reopening the connection to show the results? Just attach it to the bug report.
Hint : Don't use a grid for testing. It just makes the sample more complex.
Mark
Please don't forget to log this in the bug tracker. We all know how quickly this kind of reports sinks down the forum... Unless you immediately find the solution, of course.
fx,
Do you have a small program inserting the data, closing the connection and reopening the connection to show the results? Just attach it to the bug report.
Hint : Don't use a grid for testing. It just makes the sample more complex.
Mark
I tried again with charset NONE and reproduced the problem.cipto_kh wrote:I try using ZeosDBO 6.6.2-rc, Delphi 7, Firebird 2.0.3 SuperServer, charset: None.
There is no problem, everything save well, are you use special charset or UTF8?
The tricky part is making sure to disconnect from the database after writing the field value containing #17 or #10 because it looks like everything works fine until disconnect/reconnect.
Mark,mdaems wrote:cipto_kh, fx,
Please don't forget to log this in the bug tracker. We all know how quickly this kind of reports sinks down the forum... Unless you immediately find the solution, of course.
fx,
Do you have a small program inserting the data, closing the connection and reopening the connection to show the results? Just attach it to the bug report.
Hint : Don't use a grid for testing. It just makes the sample more complex.
Mark
I'll add the bug report tonight along with a sample project. The one I'm using has confidential info hardcoded inside so I need to create one from scratch.
Forgive me for the delay, I want to help zeoslib because I love it so much but I worked past 2am working and under heavy pressure today so it may be ~24 hours before I can submit sample project.