Script trigger upon new record?

[David Nelson]

I have set up a Preferences table finally. I just read again about it being important and that everyone has one. Everyone talks about it but nobody says how they keep to one record.

So even though my file will have hopefully correct and tight privileges and even though new records will only be allowed by button, I need to stop new records from ever being allowed in this table. Only one allowed. And if one doesn't exist, create it maybe.

Or am I worrying too much?

I first looked at field validation then layout triggers. Not sure where to even post the question, to be honest.

I should add that I tried using unique serial with ID 1 and then validate Self = 1. But CompanyName was created first and its validation happens first. Not good.

[bcooney]

David,

I have to remember that some people show the Status Bar and that has the New Record command. I lock and hide the Status and all functions are attached to buttons.

Add a RLA rule to the priv set assigned to users that they cannot add new records to the Pref table.

[Vaughan]

Make sure that all accounts (other than full access) have their privileges set up to prevent creation and deletion of records in the preferences table. Make sure all users use one of these accounts.

A startup script can check that one record exists and create that record if required by running with full access privileges.

This will provide protection regardless of the toolbar being visible or not.

[comment]

IMHO, this is not a matter of privileges. After all, you don't want anybody - not even you - to create a second record. As such, it becomes a matter of data integrity and should to be implemented accordingly.

OneRecordOnly.zip

[David Nelson]

Hi Comment,

Thank you for helping. I had originally set this up to validate with Get(TotalCount) < 2. The way it was failing is how your file would fail also in my file. It is because I have 30 fields (or so) already added to preferences and some of them have validations.

When this field is not the first one created then the validations on all fields created prior to this one fail first, requiring a Company Name, Address ... all the things I put in Preferences. I tried sorting the fields in custom order and putting this field first but it does not matter. It seems creation order can not be changed? How can I make this field be seen first or do I need to redo the entire table?

I took your example because my explanation might be strange and I changed the unique field to a standard field which must not be empty. Then I added the 'unique' field again. Now the first field's validation kicks in first. There must be an easy way to change creation order in manage database? I suppose I can re-create the table from scratch but this might be something good to know anyway and I dislike doing work unless necessary.

Hi Vaughan and Barbara,

I want to thank you both for your suggestion of privileges and I would have gone that route but I was feeling like Comment just expressed. If we can work this out, it seems the best way to go but I am always open to opinions and ideas. You both have helped me quite a bit and I appreciate you taking the time to help here as well.

And if you know how to trick FM so it thinks a field added later is the first field, I'm all ears.

OneRecordOnlyREV.zip

[LaRetta]

I'm all ears.

Hey. That's my line.

Anyway, you can select all of your fields in that Preferences table (except the one which is unique) and 'copy'. Ooops - added this: Then 'delete' the still selected fields. Then immediately 'paste' and the fields will switch to the creation order you wish. Any layouts with these fields may disappear from your layouts and you will have to re-specify them again.

added part in red

[comment]

I had originally set this up to validate with Get(TotalCount) < 2. The way it was failing is how your file would fail also in my file.

I am not sure I agree with you definition of "fail". Were you able to create a second record? If not, there was no "failure".

That said, I often add some layout measures, e.g. triggered scripts, to shield the user from Filemaker's validation dialog kicking in. But then a preferences table is probably not a good candidate for that, because inexperienced users should be kept out of it anyway.

[David Nelson]

Hi Comment,

No, I didn't mean your idea failed. It just allowed other validations to happen before it, only in my file where other fields came first. And I was lazy not to want to re-create the table. I also had not considered the User aspect so thank you. Only Admin will have access to the Preferences table layout but I want this to stop a new record even if a script breaks somewhere, Lord forbid. I would rather they get a dialog telling them that they can't create a record and leave them clueless as to what record they might be trying to create, than to create a second Preferences.

I am thinking of instead loading variables with the Preferences values so that the table itself is removed from any scripting need whatsoever. Then your validation would only affect Admin or Developers who are on that layout manually and they should understand the message.

Hi LaRetta,

I moved it to the first creation order with your idea and it then acted first. The fields from Preferences disappeared and I had to point them again to the new table but that was small thing. Even if Admin or Developer, they will receive the warning before they bother to enter all the other required data. They will now be told they can't create a second record first thing. And I also like your dog picture!

[LaRetta]

Dog? Geez. Cats get no respect ...

[comment]

I want this to stop a new record even if a script breaks somewhere, Lord forbid. I would rather they get a dialog telling them that they can't create a record and leave them clueless as to what record they might be trying to create, than to create a second Preferences.

With the validation in place, no one can create a second record in that table, under any circumstances. That is the ultimate line of defense. Everything else is cosmetics designed merely to make user experience more pleasant. Think of it as being asked politely by the receptionist, before two guys in suits grab your arms and before Rambo catapults in through the window and shoots you dead.

Dog? Geez. Cats get no respect ...

LOL. Still better than being a bat, no?

[LaRetta]

Thanks for the morning chuckle. The day always turns out better that way. Now whenever I add field protections, I will see Rambo peering in the window, getting ready to pounce.

Of course David didn't know ... I am a unique cat with bloodlines back to ancient Egyptian cats. And yeah, it is better to be called a dog (gulp) than to be called a bat ... or Yoda. :Whistle:

[David Nelson]

Oh, sorry, I thought you looked like a dog. Oh wait. That isn't really YOU anyway, right? God, I hope not! I thought it was a hairless yip-yip dog. Really I did. I did not think you looked like a bat but now that you mention it, you DO look like Yoda! You two are always funny on here.

I will add trigger protection for admin who may land on that layout. And I will sleep easy knowing that Rambo is on the job. :laugh: