Ah. Two (or more) computers are involved. That makes it dicey to delete
files except in this case it should work since you have an obvious
"master" "slave" thing going. I'm guessing that the Master computer
creates the table and the Slave is checking if the tables existe, and
when found the report is printed and the Slave erases the tables?
Is there a third system, a server, storing the tables? I still think
some file handle is not being released quickly enough by whatever system
is actually storing the table(s) that you are trying to share and then
delete.
Or I may not grok the configuration correctly.... :)
Mike
-------- Original Message --------
Subject: Re: Unexplained Error 1705 "Access Denied" Errors
From: Ken Dibble <[email protected]>
To: [email protected]
Date: 7/19/2013 12:27 PM
Are you closing the table, SomeTable1, and then trying to erase it
within milliseconds? If the tables are located on a server (instead
of your local drive) then it is likely that the server is not
releasing the handle (flag, marker, user connection) on the file fast
enough, and your application is trying to delete a file that the
server thinks is still in use. If the SomeTable1 file is located on
your local drive, then this probably wouldn't be applicable.
By the way, if you use cursors instead of tables, VFP will take care
of the deletion of the files...you just create, use, and when you
un-use, they're erased by Foxpro.
This might have been a case of the famous self-referential "Asking the
question produces the answer", for which I apologize.
I use tables because in at least some cases the actual printing is
done by a separate printing executable. In those cases, asking whether
the table is USED() in the application that launches the printing .exe
is pointless.
That aside, however, the printing .exe runs REPORT FORM... on a report
whose data environment opens the necessary tables. When the printing
.exe exits after running the report, it issues CLOSE TABLES ALL.
The printing .exe is called by tools.dll (if installed) or by
ShellExecute if necessary. In both cases, it is called in asynchronous
mode; that is, it's supposed to pause the calling application until
the called (printing .exe) application is finished. Therefore those
tables should have been closed before control gets returned to the
loop I described earlier.
I cannot be sure whether my problem always and only occurs on systems
that are using the separate print .exe. But if it does occur on them,
it shouldn't, because the tables should be closed by the print .exe
before the calling program tries to erase them.
I suppose I can put the ERASE calls inside a TRY...CATCH inside a DO
WHILE loop. DO WHILE loops scare me though.....
Thanks for the help.
Ken Dibble
www.stic-cil.org
[excessive quoting removed by server]
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
