No records allowed

[rob]

Ok. I have been reading that my file should have a null table with no relationships or fields.  This makes sense to me to use as a landing pad for incoming users where it doesn't load other files or anything.  

 

I have single record tables where I use validation to stop creating a second record (gleaned from this site) where I auto-enter data of 1 then validation says it must be unique.

 

I want the same similar protection but I want no records to be allowed so the above does not work.  I realize I could stop record creation from other methods and I will by custom menus, no access to this layout etc but there is still potential that person might accidentally create a record in this null table if something goes wrong with a script.

 

To use validation, I must create a field it seems which defeats the null table idea.  So is there a way to stop new record creation natively using auto-enter or validation?

 

Thank you for considering my request.

By the way, I can do it if I create a field and use validation of not Get(TotalRecordCount) but I must create a field to do it which I want to avoid.

[LaRetta]

Hi Rob,

 

I would suggest that you use security.  Modify the Privilege set Data Access on records to custom.  Select the Null table and set it to NO on creating new records.

[rob]

This worked perfectly except for full access.  I was trying to resolve on my own before responding with additional question if needed and I got myself in trouble.

 

http://fmforums.com/forum/topic/89565-does-read-only-access-really-mean-that/?p=411991

 

Thank you for your help here.  I learn a lot from you on this forum.  

[LaRetta]

No worries, Rob.  I appreciate that you tried to solve the additional issue on your own and your intentions were right.  As indicated on the other thread, you can't duplicate Full Access but you can create a new privilege set with all rights except the ability to add a record into the null table and it is recommended anyway for a few reasons: 

 

1) Developers should each have their own Account Name and a specific Developer privilege set so data changes they make are also tracked instead of seeing the useless 'modified by Admin.'  Even if you only have one developer, you may hire another or the developer may change.  It is important to know which developer made which changes.

 

2) If the developer can change data (usually happens with in-house developers with multiple hats), they should be held to the same business rules as other Users.  If records are flagged as Posted (critical month-end freezing from data change) then the original Full Access account would allow change without a message.  The developer (and the manager requesting it) may be unaware that the requested data change of an amount is breaking business rules.  If their privilege set also restricts from changing posted records, they will get the 'your access privileges do not allow' which causes them to pause and question the change.  The business may still want the change but it adds an awareness for those ultra-critical data changes and the developer can then switch to the Full Access account to make the change if still desired.

 

Of course for data migrations and such, all bets are off and full access is required but in a running solution, the developer should not run free-nillie in the data.