I have a client who has slowly been switching her many reports from native to an ODBC driver for the speed advantage.

We have been experiencing some odd issues in certain reports and have just realized it may be because of ODBC. Here's an example:

The client has two databases: Ticket.dbf (service tickets) and Codes.dbf (service codes). They are linked via a shared service code field (Ticket.svc_code to Codes.code). There is one codes record to many ticket records. There's a logical Group field in Codes. If the report is set up with an ODBC data source, if you ask for Codes.Group=False, you get no data returned (although both True and False records exist if you print without using the Group field in the selection criteria).

I performed several tests and work-arounds, and finally found that if I set up a formula called IsGroup and had it return a 0 if Group was False and 1 if it was true, and added IsGroup=0 to the selection criteria, it would print fine. In conversing with the client as to what do do about this (their billing is based on reports, and accuracy is very important), we realized that there seems to be more of this happening since she started switching the native to ODBC.

I then went to the original report (for where Group=False) and changed the data source to native, and, although it took minutes instead of seconds to print, it did return accurate data.

This happened both on her local machine and also on a Citrix session, so it's likely not a corrupt driver.

Does anyone know why this would happen, and how we can get it to stop? Using ODBC has saved her hours every month in print time, although now we're concerned that the data hasn't been accurate and she will spot-check that.

TIA
Joy