As we all know, FileMaker does not have a set primary key (that we have access to) as most other databases out there -- instead we can in theory have multiple fields that may act as a primary key.
As we can set attributes/properties for a field to distinguish it as unique, with a serial counter, requite it not to be null, no modifications after creation, no override, etc -- or whatever our needs are.
Then we use this appropriately in our table schema .
However, I now have happened upon the unfortunate event whereby I need to share FileMaker via ODBC and the application that is attempting to get that information can connect to my set up just fine.
It can see the available tables as well, however, it cannot connect to any of them as it requires a primary key.
The backing database the application uses is Access 2007.
Regardless of how I set my field properties, the application does not detect a primary key.
Now, I know that FileMaker has a backing primary key for each record created that we do not have direct access too, and I was expecting the ODBC provider to supply this.
Just in case I was wrong, I tried to set every permutation of properties (starting with the obvious primary-key related one's, unique, generating serial no, no modification, not empty, etc) on a field to see if it registered correctly - it did not.
As I'm certain I cannot be the first person to share a FileMaker ODBC connection with an application that requires a primary key, how have you managed to solve this?
At the moment I'm thinking I may have to create a SQL database to act as an intermediary,
is this really required, or is there a better way(I'm hoping there is, obviously)?