I've got a query going out to a Cache database via ODBC.
It almost always works (90% or so).
The other 10% of the time, it returns the wrong data for one of the columns (a LONGVARCHAR column)
By wrong, I mean the data is from another row.
At first, I though maybe there was too much text in the column and it was trashing a buffer or something, so I cahange my parameter from a VarChar to Text, but it made no difference. I just retried it again now without specifying the datatype at all, and it made no difference.
Further investigation showed that the correct data was only 1600 characters, so that isn't going to be the problem, anyway.
I've even cleared the parameters for each loop of the read and it still does it.
I just now tried to do a select specifically on one of the bad rows and it was still bad, so ti has to be something going on with ODBC or the remote server. Right?
Usually when I have problems like this, I first try and eliminate something like ODBC. Is there any way to connect natively to the database. Preferably by running something on the server that is hosting the database? If you can do something like that, it will help to eliminate whether the database itself is doing something unusual or unpredictable. As far as ODBC goes, can you try other drivers and duplicate the issue still?
Chris Meech I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
Could you post the query? Be aware that Cache ::pinch of salt over the shoulder:: isn't SQL-92 compliant and the worst thing (in my opinion) is that it doesn't support operator precedence and that could be a factor here.
When I have used it (against my will) I used an ADO.net connector when I could, but prod used ODBC. I don't recall any differences.