Page 1 of 1

Strange behaviour with ODBC query on 2.0.9.12

Posted: Thu Jun 23, 2022 7:48 pm
by Steve Rowe
This is in the same space is in this thread.

Upgraded a customer to 2.0.9.12. (One release behind the move to ODBC 3.0)

The main dataload is a TI looping over a list of ledgers, calling TIs that run queries against various ODBC connections.

This has worked happily for many years without issue.

The dataload TIs are called from the master TI using ExecuteProcess.

Since moving to 2.0.9.12, some of the queries fail whilst the loop is running. It is always the same ledgers on every run.
(Failure msg is, failed to execute query, "SQL statement", line 0)

The "interesting" thing is that if (using the identical code case) I call the load for a single ledger that fails when running the loop, it works without issue.

So no issues with infrastructure and so forth.

After analysis trying to understand what was going on I've established that if I swap out ExecuteProcess for RunProcess then the looping jobs work.

It does rather feel like there is a bug here.

Sigh...

Re: Strange behaviour with ODBC query on 2.0.9.12

Posted: Fri Jun 24, 2022 7:16 am
by MarenC
Hi,

It does sound like a bug, all I can think to check is:

Do you have unicode ticked or unticked, and have you tried running with with both? Not to resolve the issue, but to see if any news error messages appear.

Have you tried updating the ODBC drivers and confirmed the language settings?

Maren

Re: Strange behaviour with ODBC query on 2.0.9.12

Posted: Fri Jun 24, 2022 8:12 am
by Steve Rowe
Unicode is checked.
I've not updated the ODBC drivers, customer is doing some analysis in that space to understand what the versioning is across the Ledger estate.
The messaging I am getting from IBM is to move to 2.0.9.14 as there are multiple fixes in the ODBC space in .13 and .14

Re: Strange behaviour with ODBC query on 2.0.9.12

Posted: Fri Jun 24, 2022 3:30 pm
by Steve Rowe
Tested in 2.0.9.14 and get the same failure.
Rolled all the way back to 2.0.5 and working again....