FMP 8.5 adv. winXP

I thought that the scriptstep <Set Error Capture [ON]> would trap all the
errors (With the exeption of an error 100 and 803),
However in the following script this doesn't seem to work.

Set Error Capture [ON]
Save a Copy as ["MyCopy.fp7"; compacted]

I do get the error window and have to push a button before going to the next
script step. Perhaps there is a way around this, or did I overlook
something?

Ursus

I replicated your script, and my file saved without a problem.

What error are you getting?

Matt

On 01/18/2007 06:11:27 "Ursus" <ursus.kirk (AT) wanadoo (DOT) nl> wrote:

I thought that the scriptstep would trap all the errors (With the exeption

Thanks Matt for your reply.

The main file is called X.fp7 (for now at least) the file MyCopy.fp7
allready exists and I want to replace it.

The error says:

"MyCopy.fp7"could not be created on this disk. Use a different name, make
more room on the disk, unlock it or use a different disk.

When I capture the error-code it reads 800, which translates into: Unable to
create file on disk.

The fact that I was able to catch the error-code says to me that the Error
Capture did do something, but not circumventing the error itself.

The final scriptstep seems to be the problem.

Perform Script <EmptyJPG;MyCopy.fp7>

This empties one table in the newborn copy. When I simply disable this step
it indeed works. When it is enabled it doesn't. What I don't get is that at
the time of creation the external script has not run. There should be no
connection between the old and new file, but it seems that filemaker
allready deems the MyCopy to be active.

Any thought on this so far?

"Matt Wills" <Im (AT) witz (DOT) end> schreef in bericht
news:118653.ULQEIVOT (AT) news (DOT) verizon.net...

I have seen that error before. I don't think it was necessarily FileMakerish, but then, I don't think I ever figured out exactly what it was. I seem to recall rebooting the box, and it went away.

I'm thinking, though, that trying to run a script in a newly created file is confusing something.

Matt

On 01/18/2007 10:37:31 "Ursus" <ursus.kirk (AT) wanadoo (DOT) nl> wrote:

Why should it be confusing. It is just part of a redistributing process,
where the new owner gets a fully functional database with one table empty.
The redistribution is automated. In my experience when I just tell the new
user that the first thing he has to do is clicking a button to empty the
table something will go wrong. I could interupt the automation and open the
file myself and empty the table but surely will forget it once in a while.

What I could do is setting a global with an X, then on start-up it will
check if this X exists. Then empties the table and reset the X to nothing.
But the largest table would remain filled and the user would have to wait a
little longer.

Ursus

"Matt Wills" <Im (AT) witz (DOT) end> schreef in bericht
news:1181734.DNKUVLHW (AT) news (DOT) verizon.net...

You can tell if the new file is already active (open) by looking under
'show windows' to show the hidden windows/files that are open. I can't
say for sure, but one guess would be that FMP opens the new file sooner
in the script then you think. If this is the case, then move that last
step into a subscript of the X file, so that FMP won't be able to "see
ahead" until it gets to that subscript.

Or...maybe the problem is something a little different. Try adding a
2-second pause before the last step. Perhaps the problem is that the OS
hasn't yet released the lock that was on the new file from when FMP
created it just milliseconds ago. Maybe a 2-second (or less --
experiment) pause will help things get caught up.


Ursus wrote:
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Professional Solutions, Inc. Los Angeles

FileMaker 8 Certified Developer
Associate Member, FileMaker Solutions Alliance

Thanks Howard,
I have tried that. The list is empty, besides the main file there is nothing
active there. There is NO previous reference to the copy file, actualy the
only references are in the file reference list and in the script to activate
the script. Even when executing the external script it looks like the file
isn't open. But when I try to move it by hand (deleting it) I get a file
open warning by windows. So my guess is that allthough the file LOOKS
closed, it is actuale active.

Ursus

"Howard Schlossberg" <howard (AT) antispahm (DOT) fmprosolutions.com> schreef in
bericht news:12r1uk66ceec726 (AT) corp (DOT) supernews.com...