On 9/2/2011 9:56 AM, Ken Dibble wrote:
> So, given that granting him "real" admin rights on the server solved the
> problem and allowed my program to work, how is it possible that he was able
> to remotely delete a file from the server location but my program, running
> under the same login, could
Ken Dibble wrote on 2011-09-02:
>
>> If "Delete" permissions have not been set "Denied" to a group, but just
>> never set. Then an Owner has the right to delete a file.
>>
>> I've put together a program that uses some API calls to test rights. A
>> message now informs users they don't have netwo
>If "Delete" permissions have not been set "Denied" to a group, but just
>never set. Then an Owner has the right to delete a file.
>
>I've put together a program that uses some API calls to test rights. A
>message now informs users they don't have network permissions to work in the
>system. It has
Ken Dibble wrote on 2011-09-02:
> I just spoke with the guy at the location that was having this problem.
He
> reports that he got his computer consultant in to look at it, and he
found
> that the guy didn't really have administrator rights on the server
location
> where the DBF files are. Onc
I just spoke with the guy at the location that was having this problem. He
reports that he got his computer consultant in to look at it, and he found
that the guy didn't really have administrator rights on the server location
where the DBF files are. Once these were granted, my program worked co
Inside vfp :
Maybe a fopen() is pending somewhere (cause you don't CLOSE ALL but only
CLOSE DATA/TABLE)
Outside vfp :
Maybe the .DBF is opened by Excel, Open Office, ...
Gérard.
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http:/
>AUSED will only tell you if YOU have the file open, not if someone
>else on the network does. I'll bet there's some workstation in a
>corner somewhere that still has the file open. Try opening it
>EXCLUSIVE. If you can do that, then no one else has the file open.
Thanks Ted. Please see my reply
AUSED will only tell you if YOU have the file open, not if someone
else on the network does. I'll bet there's some workstation in a
corner somewhere that still has the file open. Try opening it
EXCLUSIVE. If you can do that, then no one else has the file open.
On Thu, Sep 1, 2011 at 12:40 PM, Ken
> > 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?
>
>I get this from clients on occasion. It has always been fixed by adding
>*.DBF, *.CDX, and *.FPT to the Exclu
> > 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.
>
>Is it possible that someone else has it open? You could get
>USED("MyTable") to ret
On 9/1/2011 12:50 PM, Tracy Pearson wrote:
> 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
Great answer! I
On 9/1/2011 12:40 PM, Ken Dibble wrote:
> 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.
Is it possible that someone else has
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 applicatio
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 pro
14 matches
Mail list logo