Windows 7 professional

Thank your for your report.

I understand, that for you the bug may be critical, but it does not look like that from our point of view.

We cannot repeat it - I repeated the query just like in your trace 100000 times, and all were successful. You are also saying you get it randomly. Looking in C/ODBC code I also cannot imagine how the error could arise.
I'll ask few questions, that may help. And l will lower the priority.

1) Would it be possible to try with later releases - 2.0.16 and 3.0.3

2) The testcase that reliably re-creates the issue would help

3) What server version do you use?

4) Could you please provide a bit longer trace? I would like to see what happens with statement handle used for "SELECT DATE_ADD('2018-02-01', INTERVAL -188 DAY)" from the moment it's allocated. I can see it is used for "select connection_id()" right before the query in question, but already cannot see how the result for it had been bound

5) How do you get '2017-7-26626 0:0:0' string? the result is fetched as TIMESTAMP struct. Or you just manually assembled that string for the report? I mean - have you absolutely verified, that the issue is not on your side?

Hi,

Thanks for reply,
we are facing issue frequently, and it also occurs with latest releases. 2.0.16 and 3.0.3.
when we revert driver to 1.0.6 , we did not face the issue.

we are using mariaDB server 5.5.56.0

Please provide the steps to get the longer traces?

Thanks and regards
Pratik

Thanks for your answers.

As for longer trace - just as usually, but trim it contain the issue part starting from statement handle allocation. Of the one used for executing problematic query.

You did not answer question number five.

And still the best case would be to provide standalone test, that reliably repeats the problem

Hi,

for Question 5) we are fetching the result as TIMESTAMP struct. Where we are getting the output as mentioned above '2017-7-26626 0:0:0'

attached part of code in the attachment.
Let me know if you need anything.

Thanks
Pratik

SQL_TIMESTAMP_STRUCT fields are SQLSMALLINT, which is short int. You print it as %d. Are you sure that guarantees correct values output? Could you try with %hd, and probably even %04hd and %02hd, or cast all values to int when passing them to _stprintf, or do smth like 0x0000ffff & timeStamp->month etc with them?

hi,

I will try above mentioned changes and get back. below is my observation about issue occurrence,

it doesn't occur in first few run, then once it occurs it keeps coming in next all run,
but it never occurred with the 1.0. driver with same code.

regards
Pratik

Yeah, also 26626 is short number. Thus unlikely wrong output format is the reason here.

With above suggestions we still facing same issue. i have tried all possibilities that been suggested. Please let me know how to proceed and if you need any more information form our side.

Any update ?

Well, update is that the issue is my top priority atm.
The other update is that I've seen the issue once, but could not repeat it ever since. And it did not give new clues. I am trying to repeat it again

btw, do you need the fix in 2.0 series, or would it be ok for you to upgrade to 3.0 driver?

we need it in 2.0 series as we can't quickly upgrade to 3.0 now. but in future we will upgrade to 3.0 as well.

Would it be possible to check if the problem persists with the library I have posted here?
I could not repeat the problem any more. I just changed something, that theoretically could cause something like you experience. The library is 32bit. Please let me know if you need 64bit

Hi,

Thanks for dll, I will check and get back to you.
i just need to replace dll under installation directory right? any other steps do I need to follow?

Regards
Pratik

yeah, that would be enough.
Also, I have a question. Would it be possible to verify if the problem persists with some newer MariaDB server version? I guess latest 10.2 would be best for that purpose. We have some reasons to think that might be server, and not connectors problem.

I've recalled you say 1.0.6 connector does not have that issue with the same server. Probably chances are low(that server upgrade will help).

Issue is not observed after replacing the new dll provided by you.

pnelge great! But can we take for granted that the issue is fixed, or do you think it's better to give it some more time for testing? Since it happens quite randomly.

pnelge also, did you verify, that that query returned correct values? i.e. not only valid date, but also correct date. Since I'd say it's still not quite clear what is the core reason of the issue.

I've made the job to run automatically every 1 minute. It used reproduce issue within 2-3 hours. With new Dll , I am observing from 3 days, till now issue did not occur. what changes have been made ?

Any update when can we get the official fix for this?

Any comments ?

Sorry, my mistake. The fix has been already released in 3.0.5 and in 2.0.17. I am gonna edit release notes.
The problem(and the fix) was in fact in the Connector/C.