Page 1 of 1

Wrong Firebird blob text field interpretation in 7.5.13

Posted: Tue 25 Jun 2019 18:26
by andy_bri
In version 7.5.13 the long text field is interpreted as variant array of byte instead of text.
Long text in Firebird database are stored in field of type BLOB SUB_TYPE TEXT.
And if I write CUSTOMER['NOTES'], it was treated as string (if it is not null).
But in last update of UniDAC it was changed and now it is treated as variant array of byte.
All constructions like:

if CUSTOMER['NOTES'] <> NULL then
MyMessage = 'Customer notes: ' + CUSTOMER['NOTES'];

generate execution error.

Could you fix it?

Re: Wrong Firebird blob text field interpretation in 7.5.13

Posted: Wed 26 Jun 2019 13:52
by ViktorV
Unfortunately, we haven't been able to reproduce the issue.
Please compose and send us via the contact form on our website: https://devart.com/company/contactform.html a small sample demonstrating the described behavior and the difference in behavior between UniDAC 7.5.13 and the previos version of UniDAC, along with scripts for creating and populating database objects.

Re: Wrong Firebird blob text field interpretation in 7.5.13

Posted: Thu 27 Jun 2019 11:36
by PA64
I have a similar problem in version 7.5.13, if the BLOB field is NULL, then AsVariant returns an empty string value instead of null.

Re: Wrong Firebird blob text field interpretation in 7.5.13

Posted: Mon 01 Jul 2019 13:54
by ViktorV
Please specify what value is set in the Options.CacheBlobs property.

Re: Wrong Firebird blob text field interpretation in 7.5.13

Posted: Wed 03 Jul 2019 05:11
by jpantoudis
I have a similar problem . When Blobfield is null the .Asstring does not return an empty string ('') but it returns null

Re: Wrong Firebird blob text field interpretation in 7.5.13

Posted: Thu 04 Jul 2019 13:01
by ViktorV
As indicated earlier, unfortunately, we haven't been able to reproduce the issue.
To understand the cause of the issue and find a solution to fix it, we need a test sample in which the issue is stably reproduced. As soon as we get such an sample and if the cause of the issue is in the code of our product, we will try to fix it as soon as possible.
Therefore, the only way to solve it, compose and send us via the contact form on our website: https://devart.com/company/contactform.html a small sample demonstrating the described behavior and the difference in behavior between UniDAC 7.5.13 and the previos version of UniDAC, along with scripts for creating and populating database objects.