With BEFORE INSERT triggers on both the Location and Vehicule tables, populate the primary key value using Gen_ID calls on the respective generators.
In Delphi, the new primary key values will show up once the newly inserted rows are posted. Those values will then be available for posting a new row in LocationVehicule.
Here's a pseudo-code example in Delphi (which will work if you use the Fields Editor to instantiate TField components for each table):
tLocation.Insert; // populate all required fields in tLocation   tLocation.Post;   tVehicule.Insert; // populate all required fields in tVehicule   tVehicule.Post;   tLocationVehicule.Insert;   tLocationVehicule_NoLocation.AsInteger := tLocation_NoLocation.AsInteger;   tLocationVehicule_NoVehicule.AsInteger := tVehicule_NoVehicule.AsInteger; // populate the date fields as needed   tLocationVehicule.Post;
This works with any SQL database, not just InterBase. :)
That's OK, I still get called Steve from time to time. I'm used to it.
Yes, if the data access was set up using cached updates, then posting an inserted record would not reflect the new ID until you do a full CommitTransaction, and then, only if the TransIsolation level is not tRepeatableRead.
I have used the INSERT trigger/post/fetch new key method successfully in ADO components and SQL Server databases, with InterBase 6 databases and either IBObjects or dbExpress components, and even with Oracle databases and DAO components. As long as the connection and dataset properties are set to do a commit on a post (i.e. not cached updates), this technique works.
Either way would work. The deciding question is: Will you need the Location key for further work? If so, then use the generator technique so that your application can retain the Location key for further work. If you will not need the Location key, then the trigger approach will work just fine.
Correct me if I am wrong, but doesn't your proposed solution only work if you are using TTables or "live" SQLQueries and also using the BDE? If you are not using the BDE, or if your SQLQueries are not live, but rather "cached updates", then you would need to find another approach. Don't you agree?