Hi folks,
Here's a squirrely one.
VFP 9 SP 1
I have a little program I distribute to users when an update of my software
application requires modifications to the VFP tables. This program runs in
the same directory as my main application, on the workstation of the local
administrator. The program can do various things but in this case it needs
to erase a .dbf file located on a server. The .dbf is part of a database.
Let me first emphasize: THIS WORKS FINE ON MY NETWORK, and on all other
networks that use my software. It ONLY fails on one particular network.
The program first issues:
CLOSE TABLES ALL
CLOSE DATABASES ALL
Then it runs:
LOCAL thereturn
thereturn = .T.
IF AUSED(aTables) > 0 OR NOT EMPTY(DBC())
thereturn = .F.
ENDIF
RETURN thereturn
... to make sure everything is closed. This succeeds; it always returns .T..
So then it gets to:
ERASE ("Z:\SomeFile.dbf")
And I get VFP Error 1705 "File access is denied."
The drive and path have been verified by the code before we get to this
point; other operations were performed on the same file and succeeded
before the tables and database were closed. So the path and file name are
correct.
The error always occurs in the same place, so this is not a random case of
the system suddenly dropping the mapped drive.
I know I would get this error if the table wasn't actually closed, but VFP
reported that all tables and databases are closed.
I know I would get this error if the user doesn't have permission to delete
files from the location on the server. Indeed, the directory for these
files should be configured to disallow deletion of files except by a user
with administrative rights (either local or domain). However, the user, who
has domain administrator rights, can, from his own workstation, delete a
file from this location.
I don't know what server OS this is; I know it's Windows Server
something--probably 2003 or earlier. Write caching has been turned off on
the server.
So either permissions are not working as intended, or for some reason the
file is locked even though VFP is reporting that it's closed. I should
point out that in this particular network, this particular .dbf file has
never actually been used to store data; it contains no records, so it could
not have been locked by any ordinary process.
TO SUMMARIZE:
A programmatic attempt to delete a .dbf file located on a server fails when
run by a user with proper permissions on a workstation on one particular
network, even though the table and database are closed. The user can
manually delete a file from the same server location when logged in as a
domain administrator on his workstation. This problem only occurs on one
particular network; the program works elsewhere.
My questions are:
1. Is there something about permissions here that I'm not seeing?
2. Is it possible for VFP to report that a table is closed and yet have it
still be open or locked?
Thanks for any help.
Ken Dibble
www.stic-cil.org
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/5.2.1.1.1.20110901121543.01db2...@pop-server.stny.rr.com
** 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.
