Steve,
In my case the same script has been used in, probably, a 100 or more
solutions but only on a couple of occasions has this problem occurred.
In this latest case, the client had just updated to new PC computers
running Vista (last week). He has been running the same program for a
couple of years without this intermittent problem. It started just a
couple of days after using the new computers. I will go back and alter
the script lines to 'Set field' rather than using the copy and paste
option (same layout). There are no locked records either. Last Wednesday
I placed a 'pause script' for 1 sec immediately before the copy command
and there hasn't been a problem since. This is how I overcame it when it
first occurred some years ago on XP.
Hopefully the Set Field will change this potential issue.
Lee
Steve Cassidy wrote:
On Jul 3, 2009, at 5:42 PM, Jonathan Fletcher wrote:
I didn't say it didn't work. I said it was not reliable.
In some situations it may work all the time. You just can't bank on it.
j.
In my experience, any script steps that require a particular layout
are prone to errors unless you explicitly go to the appropriate layout
immediately prior. If users have access to the layout menu, you are
almost certain to get failures at some point in time. Even if they
don't, there are cases where you might not be on the expected layout
for some reason.
Since copy and paste both require the fields to be on the current
layout, do you have such explicit go to layout steps in this case?
Is the database multiuser? Another mode of failure would be a locked
record -- locked by another user. If you have error capture set on but
do not handle this error, it might appear as if the step is not
working. This is another possibility.
All in all, there are quite a lot of reasons copy and paste might fail
in scripts. A number of them might appear to be 'random'.
Steve
--
