Devart Forums

Hi All!

Thanks for your reply and provided information.

Please be informed that we currently investigating this issue.
I want to assure you that once we have the result, we will immediately info you by reply to this email.

Thanks for the information.

We will investigate the behavior you specified and will notify you as soon as we receive any results.

Hi there!

I’m glad that your issue is fully resolved now and you can use all the features of our product.
In case you will get any additional questions simply submit a new request or reply in this topic.

Thanks for the provided information! Kindly be informed that we have fixed that bug and fix will be included in the next build of UniDAC.

We are glad to hear that you have found solutions to this issue. Thank you for your interest in our products. Feel free to contact us if you have any questions.

To solve the issue, please try to enable the option HexBlob in TMyDump, then backup and then restore this backup.

Hey Fred,

Thanks for the reply.

As we told you before, we were unable to reproduce this error in our environment. Bugs that we were able to reproduce – they were fixed.
Please send us the complete trusteddomains table script and specify the exact code you are using to set the value with which this behavior occurs.

Regards,
Viktor

Hi Fred!

Thanks for the info!

We will make changes to the Help file.
Please indicate on which version of UniDAC there was a different behavior - we will try to give you a more complete and accurate answer.


Regards,
Viktor

Hi Martijn!

Thank you for your reply!
So far, we cannot answer as to how this support will be implemented specifically, but will be able to when it will be implemented.

Regards,
Viktor

Hi Martijn!

Thank you for your reply!
So far, we cannot answer as to how this support will be implemented specifically, but will be able to when it will be implemented.

Regards,
Viktor

Hey Omar,

You can get more information about performance improving when using our components at our website: https://docs.devart.com/ibdac/increasin ... rmance.htm
Note, IBDAC components by default load BLOB fields data immediately. The DeferredBlobRead property is responsible for downloading data to BLOB fields, it is set to False by default. Therefore, to increasing performance try to set the DeferredBlobRead property to True.
In addition, pay attention to the following options: "DeferredArrayRead", "FetchAll", "LongStrings".
If that doesn't help, please create and send us using contact form from our website:
https://www.devart.com/company/contactform.html
a sample project demonstrating the issue including the scripts for creating database objects.

Regards,
Viktor

What was the type before

Kindly note that in the previous version TStringField fields were created by default for these types.

and how does dtFloat make sense for INT128?

Please be informed that INT128 does not even fit into the Delphi Int64 type, so this is the standard behavior for our components for large numbers - TFloatField fields are created by default. If you need to work with similar types without losing precision, you can use the EnabeFMTBCD option to create TFMTBCDField fields instead of TFloatField.
If you want to receive field data as a string, please use date mapping.

tsteinmaurer wrote: ↑Mon 13 Dec 2021 15:11 Viktor,

I see IBDAC 8.0.2 was released.

2) In IBDAC 8.0.1 for Firebird 4, we supported INT128, DECFLOAT and large NUMERIC types, as well as table names up to 64 characters.
The TIMESTAMP WITH TIME ZONE type is supported as a string in this release.
Full support of this type will be added to the next release of IBDAC!
We will consider the possibility of supporting isc_dpb_set_bind DPB.
Should you have any questions, do not hesitate to ask!

What is the status in 8.0.2 in this regard?

Thanks,
Thomas

Hi Thomas!

Thank you for contacting Devart and for your inquiry!

Kindly note that In IBDAC 8.0.2 the TIMESTAMP WITH TIME ZONE type is supported as a string. Moreover, we return the string in the format that the server will pass it to us. Therefore, at the moment, to resolve the issue, you can independently parse and process strings for this type.

We will do our best to add full support for TIMESTAMP WITH TIME ZONE type in the new release and set it to the highest priority.
As soon as we add this support, we will immediately inform you so that you can check it on your side before the official version with this support is released.

Should you have any questions, do not hesitate to ask!

Hi Fred,

Kindly be informed that this is the correct UniDAC behavior when working with an InterBase provider. The client libraries which are used in the application will be loaded until the TGDSList.Clear method is called, which in turn is automatically executed in the finalization section of the IBCCallUni.pas module.
But please note that you can always execute the GDSList.Clear method by yourself in your application.

Please, let us know if you have any questions.

Hi Leo!

Yes, unfortunately it is not.

Kindly note that in UniDAC 9.1.1 fields of type dtFloat are created for system types INT128, DECFLOAT, and large NUMERIC by defaul, instead of the line as it was in 9.0.1.
The TIMESTAMP WITH TIME ZONE type is supported as a string in this release as well as in the previous one.

We will try to add full support for TIMESTAMP WITH TIME ZONE type in the new release and set it to the highest priority.
As soon as we add this support, we will immediately inform you so that you can check it on your side before the official version with this support is released.

Should you have any questions, do not hesitate to ask!