I would say that the probability of any issue getting fixed is directly related to the amount of information you can provide that helps reproduce the problem as quickly as possible.
I recommend that you provide the following:
1. the smallest possible sample code / application that reproduces the problem
2. a diagnostic log that captures the results of running the sample code / application with the smallest possible data set.
To enable the diagnostic log, do the following:
1. Quit your sample application
2. Using the 64-bit ODBC administrator, select your DSN and press Configure
3. On the first panel, press "About"
4. Click on the FileMaker logo 5 times. You should see the following appear: "Log file: c:\fmodbc.log
5. Restart your application, and using as few steps as possible, reproduce the problem
6. Go back to the About dialog and click on the logo 5 more times to disable logging
7. Attach the following file to a reply to this thread of a new bug report: c:\fmodbc.log
I think that would be helpful to FMI development staff, who surely have many issues to prioritize with limited resources.
Actual Technologies - ODBC for Mac OS X
Unfortunately, I don't have administrator access. The server is property of our customer and it's difficult to sync a test like this.
Reproducing the issue is very easy:
- Set up a ODBC connection using the 64-bit ODBC driver to a simple DB.
- Create a .NET application (I'm using C#) that establishes a connection to FileMaker. A Console application will work for the test.
- Execute a DataReader from that connection with some simple query like "SELECT * FROM PEOPLE" that retrieves some data (at least one column, of course).
- Using the DataReader, invoke reader.IsDBNull(0) or reader.GetValue(0) or reader.GetName(0) and you will get an exception in every case.
As easy as that.
Other data sources than FileMaker WILL NOT throw any exception if there is a column at index 0, that is the expected behavior.