Best way to store & access constants

[kiwipaul]

We have a fairly complex application with dozens of related tables in one particular database. We build complex html files and URLs from these related tables. I'm not a professional developer however over this thing has got big and complex over many years.

When building HTML & URL's we need to be able to use characters that are normally reserved for special uses in Filemaker calculations, eg speachmarks are reserved for identifying text in Filemaker calculations.

The way we get around this is to have a Constants Table in the database. It only has One Record, and in the various fields of that record we store all the illegal/special/reserved characters such as speachmarks that we need to build our HTML and URL's. We access this One Record in the Constants Table via a relationship, then set a variable as the character we need, and then proceed to use that variable as needed.

We are about to scale our application to having many more users, and I want to be sure this method of having a Constant Table with just One Record is scalable, and won't cause record locking problems.

If we set a variable as a value from a related table, does the One Record in that related table remain locked by the user until the complete script is ended? Once we've set the variable, do we need to do a Commit records/requests on the One Record in the Constants Table to release it?

Is there a better to access constants with special character than this One Record method?

Thanks for your patience in reading my question and I hope it is clear enough to understand.

[LaRetta]

Accessing this one record, ie, setting a variable or another field with the data from a field in the one-record table, will not lock that one record; only changing a value in the one record will actually lock it if others are also trying to change the value. It will work fine in multi-user.

However, if this one table (I usually call a Preference table) is accessed throughout your solution, you might consider mirroring the fields in it as global calculations. In this way, no relationship is ever necessary with any of your tables. Globals (even global calcs) can be accessed from anywhere without relationship.

You still change the value in the standard fields (when you need to add a special character, for instance). But when you change a field's data, it updates the global calculation which resides in the same table and refers to it. Just a thought (to cut down on table tangle and reduce your relationship dropdown lengths) ...

LaRetta :wink2:

Edited December 22, 2008 by Guest
Re-worded a sentence

[kiwipaul]

Thank you, you've put put my mind at rest about our Preference File approach. Plus your global calculation is very cool as an additional technique.

[Ralpho]

I very much appreciate the tip, but I don't quite understand how to make it work. Here's what I do follow:

1) Create a table called (for example) "constants"

2) Create needed fields in that table

3) Create global calculations to mirror each field

Two questions:

1) Are those global calculations to be marked as unstored, global or... normal?

2) How do I access those global calculations from other tables?

Thank you very much!

Ralph

[bcooney]

1) Um, global calcs are stored as Global.

2) Just select them. You do not need a relationship for any globally stored field. They are available from anywhere in the same file.