In our software, every time a patient is visited by a doctor, we create a new record in a table named “Clinical findings”. This table has 1250 fields; some are calculated but the vast majority of them are user input. The doctors simply gather data and write it down in specific fields. We’re talking about ophthalmology, so you have left and right eye, which means twice the quantity of fields and somewhat explains why so many.
Users want to travel back in the past, select a clinical finding (usually the last one, but not always) and copy data from it into the current, newly created clinical finding. We are talking about 80 - 200 fields which must transfer their field data to the new record - every practice wants a different set of fields to be copied over. Duplicating the record is not an option.
Create a transfer layout and put all fields (no matter how many) that must push their data to the new record on it. Write a script to deal with that.
When the user lands on the record he wants data to be copied from, the copy script is called via a button. It switches to the transfer layout, gets all fields on it plus their content, throws their data into a $array, goes to the last record and sets the fields.
The script is totally context independent but must be called with the trasfer layout's name as parameter. It can be used in any table of mine or yours without modification, except from the New Record/Request step which exists only for demo purposes. Its true “parameters” are the fields on the transfer layout, therefore the post title.
By adding or removing fields on that layout you alter the parameters, i.e. which fields get copied over and which not. It’s a different way of dealing with the specific problem. I realise that maybe only a handful of people face the same challenge I did, but nevertheless here it is. Maybe you might twist it to fit some other needs you are confronted with.