Devart Forums

Hi StanislavK,

this issue is still so important for us, that we would like a cooperation with you to track down the actual problem so we can find the core solution.

Because you don't have an AIX at your fingertips, and we dont have your source code at our fingertips, i propose the following apprach to find a solution as fast as possible:

1. You create a patched version of the DevArt component that creates extended debug information in the part of code where the problem seems to be
2. We reproduce the problem while using your patched version of the DevArt component
3. We send you the result of the extended Debug output so you can analyze it
4. If the cause is not sufficiently tracked down, proceed with 1.
5. If the cause is found, we can continue seeking to a solution.

If you agree wich such an approach for solving this problem, it would be helpful to negotiate a time window of 2-3 days where we both have a developer ready at each side to maintain a quick debug cycle.

Please don't hesitate to contact me or Tobi for extensive negotiations. I am confident that we can come to a conclusion.

What do you think?

Greetings - Richie

Hello,

If you run a simple INSERT statement on AIX via Devart.Data.Oracle.OracleCommand.ExecuteNonQuery, a parameter of type OracleDate with a value passed as DateTime is not transferred to the server properly. The Year is not BinaryFormatted property. In particular, while the lower 8 bits of the year is passed correctly, the upper 8 bits of the yeare seems to be scrambled by the value of the lower 8 bits. This looks very much like a LittleEndian/BigEndian problem. AIX is a BigEngian-Machine while x86/AMD64 machines are LittleEndian.

You can download a test application here. If this one is executed on an AIX machine (and most likely all other LittleEndian machines) you should be able to reproduce the error.

Unfortunately, this is a quite urgent problem. Do you have a quick , or any, solution for this?

EDIT: We not only have this problem with the DATE datatype but a similar one with the NUMBER datatype as well. I think the problem has the same case.

Greetings - Richie

Thank you for this information. We are currently fixing this issue in mono. I'll inform you as soon as we got our use cases fixed.

Shalex, thanks for your answer. I intend to help fixing this issue in mono.

Do you know an already existing mono bug ticket addressing this issue?

Do you have any details about the cause of this error that would help me fixing this issue?

Thanks in advance for any help!

Greetings - RIchie