Question

There is a service running which monitors files in a folder on a server. Whenever files are copied to this folder, the files are moved and a record is written to a filemaker pro database through an ODBC connection. In that same process I need the ID of the newly created row to create a related record in another table (with a foreign key constraint). In Microsoft SQL Server, I'd use @@identity to do this, in Oracle, I'd use the sequence.CURRVAL. How would I get the identity field of a newly created row in Filemaker?

Was it helpful?

Solution

I'm not an experienced user of the ODBC interface into FileMaker, but I can suggest a possible solution that might work.

I'm assuming you're using an INSERT statement to get the data into FileMaker, that there's an "ID" number field in the table you're creating a record in, and that the ID field is set to auto-enter a serial number. If this is the case, the MAX function is supported according to FileMaker's ODBC documentation.

SELECT MAX (Table.ID) FROM Table

OTHER TIPS

Unfortunately FileMaker ODBC does not have a built in function to do this. Its a real problem.

The problem stems from the fact that FileMaker doesn't have a built in support for Primary Keys. Of course almost every table has a Unique ID, but FileMaker doesn't have any internal way to "know" what field the developer intended to be the Primary Key. That makes it impossible for the ODBC engine to know what value to give back to you.

What I think most people end up doing in this situation is to insert a UUID of some sort into a new column in the db as part of their CREATE. Then immediately Select the ID using another query with the UUID in the where clause. So you have to do two queries. The first one to insert and the second one to get the ID back.

Could you solve this by generating a unique ID before inserting the new row and then adding this ID into each record? This would enable you to identify both records after they're created.

I'd also be asking why you need this functionality. You're adding records into 2 different tables when a file is copied into a folder. Obviously, I have no idea what the solution is, so I can't advise one way or another.

My advice at this point however, would be to re-consider putting the logic of organising FileMaker data in your ODBC process. It sounds like the original record is supposed to act as a marker or trigger. Can the ODBC process be left as just a mechanism to create a record and the logic of how that record is used be left to another process, say a FM script?

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top