I’m noticing that for databases with a record id field (ie, an integer field with “+” as the default value), duplicating a record also duplicates the record id and the internal record id counter does not increment. This results in records having the same record id ‘s getting into the database. I was expecting the duplicate record to be assigned a unique id.
Curiously, the internal server record id [as returned by info(“serverrecordid”)] does assign a unique number to the duplicated record, but the internal counter for that increases by 2 when a record is duplicated. Strange, but not really a problem for the user.
Yes. Duplicating a record using Panorama’s inbuilt code is best avoided, I feel. I haven’t encountered this particular problem because I don’t use that method to create unique IDs, but there are other issues. As far as I can tell, ‘duplication’ doesn’t make a binary clone of the original record within the database, let alone do anything as intelligent as take account of automatically generated unique IDs, but just exports a record as text, creates a new record and imports that text into it. Thus any binary fields are corrupted, and any fields containing text arrays separated by carriage return and/or tab cause wider problems. (And yes, I know it’s unwise to include tabs in text fields as a general rule, but it’s very useful to use fields to store arrays, and in some contexts Panorama encourages or even mandates cr() and tab() as separators in certain arrays.)
As was once said, “It depends on what the meaning of the word ‘is’ is.”
If you asking for a “duplicate” of anything, would you consider it a duplicate if it were different from the original?
Methods matter. If I recall, using a + in the record id integer field is also dubious. There was a time, and maybe it is still a fact, when that +(1) increment would act on the integer value of the “above” id field. As long as your records were sorted by record ID, and you were adding to the bottom of the database, your record id would go merrily along, 1, 2, 3, 4 ….. But, if you had selected records with ids 1 and 2, or maybe were just on record id 2 (id 2 was the current record) and did an insert below it, that +1 would be added to record 2 id, and the records would then have ids 1, 2, 3, 3, 4.
You might look at UNIQUEID(
I’m guessing there are examples of getting your next uniqueID when a record is added, no matter what record you are currently on or what records are selected. But I wouldn’t expect to ask for a duplicate (i.e. copy) of something and expect it to be different.
exports a record as text, creates a new record and imports that text into it.
Yes, that’s exactly what it does.
any binary fields are corrupted
Yes, this doesn’t work with binary fields.
and any fields containing text arrays separated by carriage return and/or tab cause wider problems
carriage returns should not be a problem, as import/export works with those (they are converted into vertical tabs on export, then converted back into carriage returns on import).
However, tabs will not work.
mandates cr() and tab() as separators in certain arrays
There are many places where Panorama uses cr() as a separator, or a default separator. But I can’t think of any place where tab() is mandated as a separator.
I appreciate the discussion! As I’ve thought about this I’ve realized that the built it “Duplicate Record” command will circumvent ANY scheme for creating unique record identifiers. For databases with such record id fields the programmer will be motivated to create a custom procedure for duplicating records that avoids the problem. But, the user will still have the built-in command readily available on the menubar and toolbar, so there will always be a tension.
The addition of a “.DuplicateRecord” implicitly triggered procedure would be useful way to allow the programmer to handle this (and the other mentioned) potential pitfalls of record duplication that are particular to a specific database.
I don’t think the built in “Duplicate Record” is even offered via the Toolbar. But, if worth your effort, it’s possible to customize the menus to remove that from the Records menu and insert your own custom menu item replacement there with a slightly different name.
The addition of a “.DuplicateRecord” implicitly triggered procedure would be useful way to allow the programmer to handle this (and the other mentioned) potential pitfalls of record duplication that are particular to a specific database.
I’m realizing that “Paste Record” has the same potential pitfalls, so perhaps “New.Paste” and “New.Duplicate” as additional triggers for the “.NewRecord” procedure?
As a perspective on the other side, if I want to duplicate a record, then maybe change one field - nothing to do with a unique id - duplicaterecord works fine for that. And if you have too many procedures with similar names, that can get … interesting.
But if Duplicate Record in the toolbar, triggered a .DuplicateRecord procedure, if it existed, overriding the default duplication action, that would work in both unique record id and non-record id worlds.
>This statement duplicates the current record, creating a new record below the current one.
It’s not unreasonable to think a duplicate record was created, but because there was no explicit “move” command, you’d still be on the same record you were on before issuing the duplicate request.
Better: This statement duplicates …creating and moving to a new record below the current one.
If a statement does two actions, in this case creating and moving, the definition should mention both actions.
As that great philosopher, Jack Reacher, says, “details matter.”
