Brad Marks
BradM at blackforestltd.com
Sun Oct 16 16:13:38 CDT 2011
All, I believe that this is the strangest thing I have ever seen in Access 2007. We have a purchased package which uses a Firebird Database. All of the tables are defined by the application vendor. We are able to access the Firebird tables from Access 2007 via ODBC. This combination has worked nicely in numerous tests that we have conducted over the past 2-3 months. A few days ago, I happened to notice that the data on one report does not match the data in the Report's Record Source (a query). I have conducted many tests on two different PCs and the results are consistent. The data on the report is correct, but the data in the underlying Record Source is not correct. If I look at the Access "Linked Table" (Which is stored in the Firebird Database), the data is not correct (but I can make it appear correct by doing a Refresh in Access). If I view the data with the Firebird Utility called "isql", the data is correct. I have spent many hours trying different things and running various tests (and pulling my hair out). In summary... Data on Report = Correct Data from Firebird "isql" utility = Correct Data in Report's Record Source (query) = Not Correct Data shown by viewing "Linked Table" = Not correct (although I can make it appear correct by doing a "Refresh" in Access) Data as viewed via the purchased application = Correct We have conducted many tests with the Firebird Database - Access 2007 combination over the past few months, so we have some experience, but not a huge amount. My latest theory is that the problem lies in the ODBC driver. This would explain why the data appears correct with isql but appears incorrect when initially viewed as an Access 2007 Linked Table. However, this still doesn't explain why the data on the report is correct when the data in the report's record source is incorrect. Has anyone ever heard of anything like this before? Has anyone worked with Access in combination with data from Firebird database tables? Thanks for your help, Brad