record ID's, auto enter, or scripted enter?

[harryk]

When using the auto enter option to create unique record id's, there seem to be some disadvantages to that. For instance, that when re-importing the data the value is auto-entered again. Anyhow, I have to get into this more, but my general question is, do you outthere use the auto enter to make the ID's, or do you do it in a scripted way, with the creating and duplicating or records attached to buttons doing more then only creating a new record.

Or might it be possible to trick the auto enter with a calculation that catches up with the situation that an auto entered record ID is already present to leave it as it is.

(which seems fine when re-importing records, but not fine when duplicating an existing record)

I hope you get my point. Thanks in advance.

Harryk

[CobaltSky]

Hi Harry,

When importing records there are two dialogs which are presented in succession. The second of these includes an option to "Perform auto-enter options while importing (modification date, serial number, lookups etc). The problem with auto entered serial numbers that you are referring to can be circumvented if you disable this option, then selectively script updates to any values (eg lookups) that are required to be refreshed (if any).

In v5.5 and on, it is also wise to termiante the script with a script step along the lines of Set Next Serial Value["SerialNumber", "Max(CurrentFile::SerialNumber) + 1"] (where the 'CurrentFile' relationship is a self-join based on a calculated constant value field) to avoid the possibility of auto-allocation of duplicate numbers (in earlier versions a similar effect can be achieved using the DialogMagic plug-in).

In most situations, the above approaches make the use of auto-enter serial options a satisfactory solution. In a few cases, an auto-enter by calculation (where the auto enter formula is Max(CurrentFile::SerialNumber) + 1) is preferable, but if the file size is to become large, this approach can become slow, as the max fucntion is required to recalculate across the vast mass of records every time a new record is created. For files that will never become overly large, this may be an effective solution - and has the advantage of not requiring resetting of the next serial value in any circumstance.

The other options you mention may be suitable in some cases, but since they rely on scripts, there is the ever present danger that a user will create a new record without using the script provided. If the solution is going to utilise custom menus (eg via the SecureFM or MenuControl plug-ins) to constrain users so that all bases are covered and the only way a new record can be brought into existence is via the scripts you provide, then fine. But otherwise, the potential problems with this approach probably outweigh the benefits in most instances.

[harryk]

Thank you Ray.

The disadvantages of the scripted way I had also thought of..the omission of a rec-ID by choosing the FM record-commands is not something you can risk.

Some other options you mention regarding serial numbers (Max(CurrentFile::SerialNumber) + 1) I will avoid, because there will be no question of a serial number, but of some sort of Record ID, made up of a concatenation (I hope I do have that word OK now..) of the date and time and something else, there were recently very good suggestions on that matter on the board. Record-ID's are not for people, it's for FM, and may be 'complicated'. (but not longer then 20 letters/numbers).

So auto enter it will be, with the 'Perform auto-enter options while importing' OFF, and the warning to users that when they duplicate, they use the duplicated record for changes and keep the original as it is. (the other way around is a potential possibility for messing things up, if you get my point here).

Thank you. Just inventing those things not on your own but getting some feedback makes things a lot easier.

script> ..violins on the background..

Harryk

[Kurt Knippel]

See my article in the Feature Presentation - Article forum.