Ken Dibble wrote on 2011-09-01:
> 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
Ken,
I get this from clients on occasion. It has always been fixed by adding
*.DBF, *.CDX, and *.FPT to the Exclusion list in the Anti-Virus running on
the data host workstation/server.
Tracy Pearson
PowerChurch Software
_______________________________________________
Post Messages to: [email protected]
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/[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.
