Duplicating records

[longncsu]

I have a user that accidently duplicates the record she is on all the time. She does this by hitting the apple + D button. She needs to be able to edit the records and it would be nice for her to able to create new records but definetly not duplicate records. All users are logged in using the default password. I am using FM Server 5, from what I understand you can have only one default password. How do you turn that feature off? It would also be fine if all users couldn't duplicate records, I just want a way to turn it off.

[CobaltSky]

There is no native FMP method that I know of for allowing users to create records but not duplicate records. There are some other alternatives, however.

Two I'd suggest require a third-party plug-in. 'MenuControl' from Dacons International allows you to create custom menus and assign your own keyboard shortcut commands to them (you could give users everything except cmnd-D) and, with a little subterfuge, can be set up to provide different menu and key command combinations by username.

Alternatively, 'DialogMagic' from New Millennium Communications can be used to automate password dialogs, so, in conjunction with an 'opener' file, could selectively allocate users to different groups (by using different 'default' passwords) based on the username of the machine they are logging in from.

The third suggestion I will make is partly procedural - and may or may not be appropriate, depending on your business rules and requirements, and the design and user interaction paradigm of your database. However you may wish to consider removing the 'create new records' privilege for all users of the default password, and instead providing a floating allocation of blank records which can be filled in as required (and a script which users can use to locate the first unused record, 'claim' it and set the date, created by etc flags).

If you are considering this last approach, you might want to add some steps to the start-up script on the server (or any other script which runs on a frequent basis) to restore the required 'buffer' of new records (checking how many unused records remain and creating additional records to maintain a workable 'headroom'). Consideration would also have to be given to modifying 'find' and 'report' scripts to ensure that 'blank' records are omitted.

There are some situations where variations of this last approach is ideal - and others where it can be problematic. I'll leave it to you to consider the pros and cons in respect of your particular needs.

[longncsu]

I like your third suggestion, but I am a little unsure how to do either one them.

1. When you mean the "add a start-up script to the server," do you mean FM Server? I know you can add scripts to the Server but never had a reason to until now.

2. I can attach a script to a frequently run script but since no users can create new records, how will the script create a new record?

[CobaltSky]

What I was suggesting was that the host machine (server) be launched with a password which does have record creation privileges, and that a script be scheduled to run at start-up on the host, which will check how many unused blank records remain, and then create some additional ones to restore the desired 'buffer'.

So, lets say that you rarely have more than about 50 new records created on any given day - you might conclude that a floating pool of 75 unused records is adequate. Lets suppose also that you've chosen to identify the blank records by inserting the string " ~New Record~ " into a clientID field (which maens that you will be able to readily identify which records are null so that they can be ignored in summaries and omitted from reports etc.

You would then need to create a script which runs along the following lines:

Set Error Capture [On]

Enter Find Mode [ ]

Set Field ["ClientID", " "~New Record~" "]

Perform Find [ ]

Loop

Exit Loop If ["Status(CurrentFoundCount) = 75"]

New Record/Request

Set Field ["ClientID", " "~New Record~" "]

End Loop

---

Whenever the pool of 'spare' records is getting low, the script will need to be run on the server to top it up again. If seventy-five (or whatever number of records you choose) is enough, and the script runs routinely once a day, users should always have a fresh supply of records awaiting them.

Hope this explanation gives you something to work with?!