Michael:

>How does it happen that you don't know what relations are set in the program?

I suppose, strictly speaking, the answer is that I do know what relations are being set in the programs. However, I have a function which does a number of things with tables. Bear in mind this is a 2.6 system. If I want to use a table, I call this particular function with certain table properties that I want to set. The function records the current properties to an array for that table in that particular session. At the end of the process, I call a RESET_ALL in the same function which puts every single table back in the same state they were in prior to calling my MyUsed() function.

I wanted to extend the functionality so that I don't have to worry whether a table that I wish to use as a target in a relationship may already be a target in another relationship. Whilst this scenario is highly unlikely, it could occur. I have now included another parameter which if set true (and is set true if you know you are about to use the table as a target in a relationship) checks to see if the table is engaged in another relationship. If it is, it records the parent table that is controlling the relationship. It then writes the relational expression and the controlling table alias into an array. A "Set Relation Off Into" is performed to avoid the "Target already enaged in another relationship" error. The table is question can then used as a target in a relationship. No thought required.

When the job is complete, the RESET_ALL call, re-instates no only the properties of a number of tables but also, where appropriate, the original relationship just as it was. It then disappears without a trace.