Never Copy/Paste?

[MariaAux]

I once remember reading that it is unreliable practice to use Copy / Paste in scripts. I have a looping script that copies data from one table and paste it in another as it as it creates 150-200 new records. I notice that here and there, a few records are missing their pasted data.

Should I replace 'Copy' with 'Set Variable' (Using only one $ for that script?)

and should I replace all the 'Paste's with 'Set Field'?

Or is there a more reliable way to do this?

Thanks so much and a very happy new year to you!

[bcooney]

Yes, export and import or Set Fields (using a relationship, if you can rather than setting $vars first).

I question why your data is redundant across the two tables.

[comment]

I notice that here and there, a few records are missing their pasted data.

There are very good reasons not to use copy/paste in scripts - however, I don't believe reliability is one of them. I'd look for another cause of the problem.

[MariaAux]

Thanks for the feedback

Yes, export and import or Set Fields (using a relationship, if you can rather than setting $vars first).

I question why your data is redundant across the two tables.

I have got a 'students' table and I want to create Tuition records for each of those students for each month. Through a script, I find all the active students, create a record for each of them in the Tuition Table inserting their student number and which month they are paying. Thus in a 3rd Table - Cashbook, I have a Portal showing all of the Students who need to pay this month.

...or have I structured this poorly?

Thanks so much,

A wonderful new year to you!

P.s. For Curiosity, what are the reasons never to use copy and paste in scripts?

Thanks again

[bcooney]

OK, so you're populating a key field in a child table. That's not redundant at all.

Copy/Paste isn't used bcs it changes the user's clipboard. What if they had something there that they needed?

[LaRetta]

And with copy/paste, the field must be on the layout ... no such restriction with Set Field[].

[comment]

...or have I structured this poorly?

Hard to tell. What makes a student "active"? Perhaps you only need to record actual payments as they are made.

what are the reasons never to use copy and paste in scripts?

In addition to what Barbara said (and more importantly, IMHO) you always want to work at the data level - unless your script is assisting user in their data entry. That way your scripts do not depend on what fields are or aren't on the layout.

[MariaAux]

Aha, I got it. That is why I had to run around to layouts during the script in order to copy. I'll delete those steps now.

You guys are just a plethora of knowledge.

I grand new year to all of you.

Thank you,

Maria

[MariaAux]

Whilst we are on the topic, What if we wanted to copy several fields (E.g. Payment Account, Payment Amount, and Payment Date) into a new record. For example, a client is on the tuition list. but has paid via the bank. I still want his record to show up in the list of Tuitions, but I also want to reflect that his payment has been paid into our bank account rather than by cash. The 3 fields above would need to be replicated into Bank::BPayment account, Bank::BPayment::Amount, Bank::BPayment Date.

I tried going back and forth, but there is no option to go to to last visited record, so I would need to 'Set Variable' (Copy) all 3 pieces of information, and then dissect them with a formula when going to the other table? There must be an easier way?

Thanks so much,

[MariaAux]

Wait Don't Answer that. I just had a brainflash. Set Variables for all 3 Fields at the same time, and then go to the new record and Set Field in the 3 appropriate fields. Just tried it and seems to work. Sorry to post and then answer my own post.

Have a great day!

[comment]

Another option is to find the source records you need, then import them into the target table.

Though I must say that your latest example is puzzling. Why would payments made through a bank be recorded in a different table than those made in cash?