Does anyone know of a slick way to produce a list of either layout names or layout ids based on a selected table occurrence. In practice the user will select a table occurrence from a drop down. Then a script would be able to navigate to a layout that displays data from that selected occurrence. I know that I can manually create a join table that holds occurrences and their respective layout names (or ids), but I'm wondering if there is a way to do it on the fly.

Perhaps there is something that the ExecuteSQL() function could do? Something along the lines of (and I know that this is not a valid statement):

ExecuteSQL ( “SELECT * FROM LayoutID WHERE TableName=’" & [table occurrence selected by the user] & "'” ; “” ; “”  )

Perhaps the FileMaker help is what you are looking for.

Reference > Functions reference > Design functions > LayoutIDs

 

The LayoutIDs function returns a list of all layout ids in the database. I am looking for a way to return only the ids of layouts associated with a selected table occurrence.

I am not aware of such function. Of course, you could compile a "directory" of layouts by looping among them and using the Get(LayoutTableName) function to see which TO each one belongs to. However, it sounds like your real issue is elsewhere; how do you find yourself in a situation where users need to select a TO from a drop-down?

The purpose is part of a custom data export script. A short description of it is that a user is able to pull specified data from any table in the database into a temp table that can then perform any kind of data manipulation tasks and export either a flat file or XML block. The idea is that any number of custom exports are handled all in one place by a single script. It doesn't require any new tables, layouts, or relationships to create a new custom export. Any user can use it without putting data integrity of the primary tables at risk and without the developer having to get involved.

From the standpoint of the user, while the data source could be selected from a list of layouts, it makes more sense to designate a table occurrence as those more reliably reflect the relationship structure. The hangup comes from converting that selected occurrence into a layout id that the script would need to navigate to in order to retrieve the data.

I don't think that users are supposed to understand table occurrences. A table can have occurrences designed to facilitate conditional value lists, or filtered relationships or any other number of purposes, and no one can understand what any TO's role is without looking at the relationship graph - and perhaps not even then ;-) .

IMHO, you need to limit your user choices to tables specified in a table (or in a custom value list), and have a predefined layout for each such choice stored in the same table (or in a parallel value list, or in the script itself).

IMHO, you need to limit your user choices to tables specified in a table (or in a custom value list), and have a predefined layout for each such choice stored in the same table (or in a parallel value list, or in the script itself).

This is the exact conclusion I came to myself. Thanks for the insight.