ODBC数据检索问题

Question

I wrote an app to pull data from a ProvideX database, and after a while I noticed that some fields were returning null, even though I knew they had data in them. I confirmed this in Excel/MSQuery.

I couldn't figure out what I might be doing wrong, so I pulled out the code that directly deals with the query, and ran it in its own project. It pulled the data properly, even though it was the same code in the actual app.

In my app, I use both ODBCDataAdapter and ODBCDataReader. I use the adapter.Fill() first, and if it fails, the app uses the reader. Both of these have the same behavior I outlined above: inside the app they fail to properly retrieve some fields, outside the app by themselves they work as expected.

Can anyone point me to some possibilities that might cause the ODBC stuff to have such issues?

I guess I should clarify that I am not asking what is wrong with my code, but rather, general troubleshooting hints as to what might cause this issue for the ODBC framework.

EDIT :

Ok, let me add some more info here...

The main problem seems to be in the DataReader code, specifically the Read() method. For some reason, inside my app, the Read() method takes at least a second to execute and many times it takes a bit over 3 seconds. By comparison, outside my app, the entire query code, including populating the DataTable, runs in under 30 seconds. This is for about 3 thousand rows with 370 columns.

The while loop...

// Column ordinals cached
// I pared down the code inside the while loop, populating a list of
//  arrays (rows) to hold the raw data. This was the quickest way I 
// could think of to do this. TryGetValue is an extension method 
// that handles null exceptions.
while(reader.Read())
{
    var arr = new object[reader.FieldCount];
    for (i = 0; i < arr.Length; i++)
    {
        arr[i] = reader.TryGetValue(ordinals[i]);
    }
    rows.Add(arr);
}

Why the difference??

Answer 1

Ok, after much testing, I narrowed the problem to a single Date field that was somehow throwing the whole query off. I dealt with this by adding a rule to skip that column when querying the ProvideX database.

I'm afraid I can't yet say why that field does not get along with ODBC, still waiting to hear from the vendor (not even sure if I ever will). I do know that this ProvideX database is a flat file database, so I guess they had that particular field set up badly.

I hope this helps others who may find themselves dealing with such an obscure database...