As I put together a solution that I intend to offer to several different clients, I'd planned to have a table called SETTINGS, populated by global fields, where they could adjust some variables. For example, I can write the calculation that opens event registration X days before the event, but they can decide how many days that needs to be. Another example: I can write in email functionality that they can use if they want to provide their own SMTP server data.

 

I'm just learning, though, that global information can end up purged on a hosted file. And while there might be workarounds for that, it means that this isn't a rock-solid solution, so I'm in search of another one.

 

These are variables I definitely want the client to be able to alter, so they can't be hard-coded in auto-enter calculations and stuff, and I'd like to include them in a graphic layout (so I can use tabs to simulate a wizard for some less-intuitive stuff that some folks aren't used to thinking about - like those SMTP credentials). They're not variables, because the ideal case is 'set and forget.' I'm looking to have them all grouped together so that a client can find them - maybe behind an "administrator's" account whose privilege set extends to a dedicated layout.

 

Looking for creative, effective ways that you might have solved this in the past.

Idea is good, just dont use globals but have only one record in Settings and use 'normal' fields....

As DDDan said, a one-record Settings table with normal fields is the way to go.  Relate a TO of Settings to each TO which needs Settings data via a Cartesian, or X relationship. You can set privileges for the Settings fields to allow or deny alteration by most users, and allow an Administrator account to change all of them.

how would you disallow the accidental creation of new records? I guess via a custom menu? Maybe a custom menu, plus an autofill rule that will insert the value of each field into the same field in the accidental new record, and then maybe a self-check when the database is opened that deletes all but the oldes (i.e. original) record.

 

That seems like a lot of overhead, but I'd be concerned about the results if someone accidentally hit Ctrl-N, which after all is a common command.

For a single-record table, you can do this:

 

Create a single field - I call it OneRecordOnly.

 

Set auto-enter to 'data' and type a 1 in the box.

 

Go to validation table and set it to always validate, removing ability for it to be overridden and check 'unique.'

 

You can put a message if you wish but truth is ... you should highly protect from access by regular Users, using Security and also using custom menus to restrict key-combinations for New Record etc.  Create scripts which must be used for creating new records.  The scripts can be attached to a button or custom menu.

Its not so much work to avoid that people create extra records by using a custom menu.

And as an extra in the startup script you could verify if there is only one rec. if not, it omits the first, and deletes the others. It can also check if the other unlikely scenario happens: the one record that should be there gets deleted. (With a custom menu this is easily avoided, but still.... You might have done it yourself in admin mode)

In that case the solution can ask if it is starting from a clone, and then it can create a record and prompt the user to fill in the needed info...

Custom menu's are way to go in general. For me its standard to script new, find, delete, etc.

Gives you great control over the user experience.

how would you disallow the accidental creation of new records?

 

If you don't want users to create new records, deny them the privilege to do so in their privilege set. That's where it's at.

Relate a TO of Settings to each TO which needs Settings data via a Cartesian, or X relationship.

 

I would much rather populate global fields and/or variables on startup, than add to the graph.

Yes comment, for some things I agree. But in some solutions there are typical values that need to be user adjustable like start of high and low season of the current year, nominal accounts for for invoices, allowed book years/months, default payment book, etc.

Some of these might even differ from user to user. I often end up with a settings table with one record for general settings, and a user table for user preferences with a record per user. (Like default go to list or form view, open some tools in separate or main window, etc.)

Dan

for some things I agree. But ...

 

I don't see why you say "but". Did I disagree with any of the things you say after the "but"? I only took exception to your suggestion to use custom menus (with or without the help of a startup script) to prevent users from creating new records.

Hi Comment,

Dont worry, I'm not a native English speaker and in my language 'but' is an overused word that can connect almost anything in a sentence.

Unfortunately (?) language is not like code, where you get a syntax error when you do not express yourself correctly... :-)