Jump to content
Salesforce and other SMB Solutions are coming soon. ×

Limit a table to only 1 record


iankh
 Share

Recommended Posts

I'm not sure this is possible, but I want to set up a record that contains user preferences. Depending on what's selected layouts and menus will trigger.

 

My question is, how do I limit that table to only having 1 record. Meaning, there can ever only be 1 record for user preferences and never anymore than that.

 

Is there a calculation or valaidation I can do to prevent the user from creating another preferences record accidentally?

 

Thanks.

Link to comment
Share on other sites

If it's going to contain user preferences and there's only ever going to be one record, does that mean there's only going to be one user, ever?

 

If so, why bother with "preferences"?

 

If not, then presumably you want one record for each user

 

The answer to your question, is "yes". You can have a table where the Access Privs are set up to disallow the creation (or deleting) of records for all accounts but [Full Access]. I use a table such as you describe. It loads different parameters into persistent $$variables at logon time for each user.

Link to comment
Share on other sites

Yes, there will only be one user.

 

I want to use the user preferences to determine which menus and layouts are available for the user, so depending on what they select there they will be limited to the appropriate set of layouts or menus.

 

What I am creating is a vacation planning tool. If the user is a Vacation Club member they have access to layouts for managing their contracts, vacation club points and vacation club point bookings. If they're not a vacation club member, the many of the layouts and tables are not available for them and they are limited to booking and planning screens for cash bookings only.

Link to comment
Share on other sites

I didn't mean "only one user at a time" I mean "only one user, ever, period, end of story". If a user can either be a Vacation Club member or a nonmember, that's at least two users (unless your user is Joe Schmoe and you know in advance that you're kicking Joe Schmoe out of the vacation club in November).

 

Most developers would have it so that Joe Schmoe logs on with username and password, and has a Privilege Set associated with his account, which either does or does not give Joe Schmoe access to Vacation Club features of the database. Other developers would have the database set up to log in everyone with the same FileMaker account but type in a secret Vacation Club member code at logon time, in a Custom Dialog perhaps, and if they have one it sets a global field to a value which is then referenced in the various calculations in Access Privileges that determine whether that one account should give the user access to Vacation Club features of the database. Yet other developers would use a table, containing preferences and other info about the user, and at logon time would have the user type in identifying information into a global field and then do a Go to Related Record to get on the right record (or else have them enter their identifying info in Find Mode and then do an Error-captured Find to get to the right record), and then load values from that table record to determine (among other things) whether the user should have access to Vacation Club features of the database.

 

The latter seems to be what you're designing, and if all you need privilege-wise is YES or NO to Vacation Club features I think you should go with one of the other two designs. The usefulness of the third method is if you've got (let's say) 18 people who have Vacation Club memberships but different preferences and different personal info that you need to reference in scripts, fields, and layouts in order to make the database behave properly for them as individuals; and then 81 people who don't have Vacation Club memberships but you need unique individual preferences and personal info for them, too.

 

If you do go with the latter model, you'll note that it is a multiple-record table. A one-record table can't (elegantly easily or conveniently) tell the database how to behave for different people.

Link to comment
Share on other sites

Probably my confusion is due to the fact that I'm not a developer and only a good Excel user. So, it's a miracle and to the credit of FM that I have gotten as far as I have.

 

This meant to be distributed as a runtime version. So, in my mind while there could be many users, for any one runtime instance there will only be one user.

 

There are two paths, vacation club member and non-member.

 

There are separate layouts, etc, depending on the with path. Ultimately there will be different menus (note - note everything is separate, thre are some common layouts).

 

I do have buttons/scripts that do fire correctly depending on the preferences (there aren't a ton on them, only two that have downstream impact).

 

In the preference table, all of the fields are global. I suppose that it's irrelevant if they add records. They can add as many as they want, since the fields are global, there'll only ever be one setting anyway. To be tidy, I had wondered however if there was a way to prevent them from creating additional records.

 

I suppose that I could create a custom menu for the layout and just remove "new record" from the menu, though I'm not sure if there is a way to remove the command-new shortcut.

Link to comment
Share on other sites

Ahhh so.

 

In that case your design makes sense. Each specific copy of the database itself will be used by only one user, but you're distributing multiple copies thereof.

 

And therefore, in that case, I withdraw my objections, your design makes sense :)

 

(You could still do it in any of the other two ways I described though).

Link to comment
Share on other sites

No problem - I realized that my orginal question might have sounded odd.

 

Now if I could only get my head around how to filter records in a portal. I still can't get it through my head.

 

What makes it even more absurd is that it is for a luggage packing list function which out of the entire system is the hardest thing I've created.

 

I still can figure out how to get the portal to show the following:

 

Selected for the packing list

 

or

 

Not selected for the packing list

 

or

 

Show all, both selected, not selected and blank (neither selected or not selected)

Link to comment
Share on other sites

This thread is quite old. Please start a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share



×
×
  • Create New...

Important Information

Terms of Use