Copy and Paste Multiple Fields

[Brien Applegate]

After messing around with the table view, I just discovered that you can't copy and paste multiple fields like you can in Excel. This functionality is very important to one of my clients and I was wondering if anyone has come up with an elegant way of addressing this problem.

Specifically, the client would like to copy most of a given row (but not all of it so duplicate won't work) and tab down the list pasting it (but not in every row) with keyboard shortcuts.

I thought about just having copy and paste buttons for each row in Form View, but this still isn't as easy as being able to use arrow keys or tabs.

Any ideas?

Thanks,

Brien

[Vaughan]

Use the Replace Field Contents command, in the Records menu to replace all records in the found set. Otherwise you can drag and drop the values into the fields.

[Brien Applegate]

Thanks for the quick reply Vaughn. Let me clarify my inquiry though. I would like to be able to copy multiple fields at the same time. For example, in this time sheet program I would like it to be able to copy all of the clock times for a given row - Time In, Lunch Out, Lunch In, Time Out - and allow the user to paste those values into other select rows without having to do each field individually. Not every row in the timesheet will have the same times, but most of them will. I think this is critical spreadsheet functionality that FileMaker lacks.

Edited October 21, 2008 by Guest

[Vaughan]

If this is a regular function then it could be scripted. Rather than use copy and paste, set the values into global fields (or global variables) as temporary storage, then set the fields in the other record using the stored values.

"I think this is critical spreadsheet functionality that FileMaker lacks."

That's because FileMaker is a database. Designing databases to look and act like spreadsheets is not optimal.

I'd look deeper into the issue and try to work out what the real needs are.

[Søren Dyhr]

Designing databases to look and act like spreadsheets is not optimal.

Shouldn't we rename it the Ryan Rosenberg Syndrome???

--sd

[Brien Applegate]

Basically, this is an invoicing system that tracks AR and the invoices are derived from employee time sheets. I think it definitely needs to be a relational database.

The time sheets do look very much like spreadsheets, but this data is needed for everything else and importing each individual time sheet from excel doesn't seem like a good solution either.

Right now, I just have a copy and paste button for each row, allowing the user to copy all of the times from a row then click paste in the rows they want to paste the values. This is just a lot slower than using the keyboard and doesn't handle unique situations. I guess I'm just surprised people don't run into this a lot, but I'll keep it this way if no one has found a better solution.

Thanks,

Brien

[Søren Dyhr]

But the bare need to copy something to one or more locations is pretty much against the whole idea of a relational database, in this case does it looks like the data should remain in a transactions table ... and actually stay there!

Making the transaction show up under an employee's or several employees timesheet(s) should be solved via a keyfield providing the linking.

Which cure to your problem that suits this tool best, can't be established purely on your expirienced lack of crossover functionality. The abstactions level presented is similar counter productive.

We need to know how the relational context is established or reached, the danger is here that yet other spreadsheet'ish metaphors is supposed to rub off as well - linking sheets isn't nowhere near relational approaches and could therefore not be chosen quite as arbitrarily.

I would guess that a few many to many relations exists in this scenario urging the establishment of key-fields of no meaning to the user and therefore never shown on user accessible layouts, how would copy and paste be able to grap such urgent field values?

You can however study this to get some idea of how this "obvious" relational content could be handled:

http://fmcollective.com/2007/04/18/creating-multiple-child-records-from-a-list/#more-26

--sd