I presume the menu duplicate records option copies a record with all data in it. I have a database with rather a lot of fields defined, and I notice that using this command duplicates not all of the fields. Some formatted numeric fields in the record are not duplicated, some others are, and all text fields are copied as expected. All this in browse mode of course.

Said in other words, when I duplicate a record, and I compare the both of them, the copy has some formatted number fields set to 0,00 where the original record had a number. (No globals, no calculations, just number fields formatted as money-decimal)

I can't figure this out. As there are often reasonable explanations beyond my simple mind, which says, duplicate is a copy of the original, I am curious..

Might it be some sort of bug, or has it to do with the many fields I have defined? Or can a certain field validation cause this?

Harryk

As often, the light comes over me just after a little or longer while, and I provide my own answer.. the reason is the auto enter function for the field. When this is activated, Filemaker takes the auto enter value, not the value of the record duplicated.

A lot of number fields I provide with a auto enter of a value zero. This to force the field to show 0,00 (in decimal format) instead of being empty.

Though I understand while filemaker does this, taking the auto enter value is especially useful with serial numbering the record, also the duplicates; I am not to happy with it at the moment..

Harryk

Any auto-enter options that you have set for the fields will override the existing data. So, if you have defined a number field to auto-enter the value 0 when the record is created, then you will get zero rather than a duplicate of the data from the original record.

Try autoenter-ing a calculation, where the calculation does not change the value if it's different from the default.

Forget that... the best way is to forget the auto-enter and script the creation of new records (and duplicates). Simulate the auto-enter using a set field step, but only do it if the value is empty. This will handle new and duplicated records easily.

The thought of scripting the making of a new record has indeed occurred my mind (sorry, is this english..). The calculation thing for auto-enter (which I should forget..) is interesting but a littlebit complicated. The auto-enter zero for a lot of fields is from the point of the user in fact not a problem so I leave it as it is. From the developer's point of view, fast creating of a lot of dummy records for testing purposes, that was the thing that made me not to happy.