Ability to Truly Duplicate a Record

[Matt Klein]

I'd love to have the ability to easily Duplicate a record without performing the auto-enter options.

FileMaker has had a Duplicate Record/Request menu item and script step for years. The problem I have with it is that, if you have any fields setup with auto-enter options, it doesn't really create a duplicate record because the auto-enter options of all the fields fire off thus changing the data in those fields on creation of the duplicate record leaving you with a record that is NOT a duplicate.

I have worked around this by scripting the export of all fields to a FileMaker file and then immediately importing the data from the newly created file using matching names and NOT selecting the "Perform auto-enter options while importing" checkbox. I shouldn't have to export and import to get a true duplicate. While it works just fine there is one major drawback....If a field is added to a table, you need to remember to go to your "Duplicate" script and add that field to the Export order. It is very easy to forget to update the export order.

Maybe add an option to the Duplicate Record/Request script step/menu item that allows for duplicating a record without performing the auto-enter options?

[bcooney]

This is an interesting request. I cannot think of a scenario where I needed an absolutely duplicate record. Can you provide an example?

[Vaughan]

Maybe add an option to the Duplicate Record/Request script step/menu item that allows for duplicating a record without performing the auto-enter options?

What about fields such as primary keys, that must be unique?

[bruceR]

FWIW I have had clients ask to duplicate complex orders (order + line items) as starting points for a new order that will similar to the prior order; then to be modified. But they also specify a long list of particular fields that need to be cleared or set with default data.

[Matt Klein]

In my case, I create an exact duplicate record and mark the original record as "inactive" temporarily. Marking it "inactive" entails setting a flag and appending data to the primary key and has the effect of making it inaccessible to the users. The users then modify the duplicate record. The purpose of keeping the original is to give them the option of reverting back to the original at any point prior to marking the duplicate as done which can be several days after the first mods are made to the duplicate.

This isn't really pertinent to the discussion but....if the users mark the duplicate as done, the original record is permanently deleted. If the user chooses to revert back, the duplicate is permanently deleted and the original record is re-activated by clearing the flag and removing the appended data in the primary key.

[Rick Whitelaw]

In my case, I create an exact duplicate record and mark the original record as "inactive" temporarily. Marking it "inactive" entails setting a flag and appending data to the primary key and has the effect of making it inaccessible to the users. The users then modify the duplicate record. The purpose of keeping the original is to give them the option of reverting back to the original at any point prior to marking the duplicate as done which can be several days after the first mods are made to the duplicate.

This isn't really pertinent to the discussion but....if the users mark the duplicate as done, the original record is permanently deleted. If the user chooses to revert back, the duplicate is permanently deleted and the original record is re-activated by clearing the flag and removing the appended data in the primary key.

In my opinion, in a truly relational database, there is never a case to be made for duplicating a record . . . flagging or not. the whole idea is to have each piece of data in one place only. if there is indeed a reason to keep a duplicate record, I'd ( really) like to hear about it.

Rw

[Matt Klein]

In my opinion, in a truly relational database, there is never a case to be made for duplicating a record . . . flagging or not. the whole idea is to have each piece of data in one place only. if there is indeed a reason to keep a duplicate record, I'd ( really) like to hear about it.

Rw

As I noted, in the end, each piece of data only exists in one place. I believe both BruceR and I made cases for creating exact duplicates. In both cases, the duplicate is a temporary item. In BruceR's case, the client simply uses it as a starting point for a new record rendering it a unique record almost immediately. In my case, the duplicate is temporary and ultimately, within 1-2 days, removed entirely.

P.S. A case can be made for anything in life. Developing in FileMaker is no exception. To each their own. That is what makes FileMaker such a great development environment.

[comment]

I believe both BruceR and I made cases for creating exact duplicates.

Not exactly. You are talking about prolonging the period during which a record can be edited - and still reverted back to original. Whether an "exact duplicate" is the best method to achieve this is another question.

One should also consider the implications of record locking (or rather the lack thereof) in this situation.

A case can be made for anything in life.

In postmodernism, maybe.

[Kris M]

Ray Cologon & crew have a nice method of duplicating records and all related records...

http://www.nightwing.com.au/FileMaker/demosX/demoX06.html