Sweet

I have an "Element" table that's been discussed and shown in the <U>As Gordon would say</U> post of the <U>Helper Data</U> thread. This table has a very specific format for the records.

One might consider control tables for the backend and frontend. I have generalized tables there that would be a little difficult for the casual user or any hacker to decipher. In those tables are a host of "control" data for procedures and application modules to use.

In the image above, you are only seeing the columns for Text fields. There's other fields (to the right that you can't see) for integer, currency, double and boolean control data. When the database is split, the frontend table remains with the frontend .accde.

Elegant solution. I do something similar in my SystemValueT table for the website. I have an ID and then a short text field, long text field, date field, and number field so that I can use any one of those for a system value. The coding determines which one is used.

Thomas Gonder wrote "When the database is split, the frontend table [called Elements] remains with the frontend .accde."  My Element table has office-native info that populates combo boxes, but also customer-specific data like "Orders on Tuesdays" and "Tends to drink too much".
   I'll have to draw on a Rost technique and make-table in VBA to split office-native info so it follows the front end. That way there's no 0.75 second delay for the office-native info to populate my combos. Is that how you would do it?

@ Jason Things that control programs stay in the frontend control table, like color of objects. Sometimes I put controls in the backend control table if changing it would violate some security or control of how the application works. For example, if I don't allow deletion of a record (by a parameter in the CntlX table), then I don't want someone changing the local field to allow it on just their frontend (so that control field stays in the backend).

As to data for combo boxes, that I consider data under the control of a "data administrator" and are in the Element table. As a developer, my "job" is to let the user have their data any way they want, in any possible language (supported by Access). But, I don't want a local user changing the Element data for combo boxes that all other users on the backend wouldn't be able to see or that would cause foreign key errors if not in the other (nonauthor) frontends. For that reason, I have to suffer the small performance hit.

I may be wrong on this, but it seems from my testing that Access caches the Control and Element tables in the memory of the frontend computer. I've watched network traffic while populating a large form or combo box the first and subsequent times and network traffic is way down on the subsequent hits.

@ Jason One final example for the Cntl tables (since I got a note that my last message was getting too long). I have a version control field in both of the CntlX tables. The frontend has to match the backend, or the user can't login. This way, someone can't just grab an older (or newer) frontend and just start corrupting the backend data.