Skip to content
View in the app

A better way to browse. Learn more.

FMForums.com

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

No records allowed

Featured Replies

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.

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.

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. 

Create an account or sign in to comment

Important Information

By using this site, you agree to our Terms of Use.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.