VFP Read Only Error

[Bill Leavy]

Hi -

I've run into a strange problem. I've written an app in VFP 9.0, and
it has been compiled into an .exe to run in a runtime environment.
When it tries to write to the data files though (dbfs, not cursors),
it always gets a "Cannot update cursor ______ since it is read only"
error. I'm pretty certain the problem is environment related, but
just to be sure, I simplified the problem by making a small program
with a form and command button. The click of the command button
executes a few lines of code...

USE test
WAIT WINDOW IIF(ISREADONLY("test"),"File is Read Only","****File is
NOT Read Only****")
CLOSE ALL

where "test" is a free table that is NOT included in the project.

I've made sure that the tables are not included in the project.

This program is run in a Windows Server 2003 environment. Here is the
curious part...

With the .exe and test file on the server, the user gets the "read
only" message, but when we move both files to his own hard drive, he
gets the "NOT read only" message. Same user running the same program
in two different places and getting two different results.

Looking at the dbf file on the server, properties of the file show the
"read only" attribute unchecked. On the security tab, all users have
write, read, modify and execute rights.

I'm at a loss to explain what is going on here and not even sure how
to further debug it.

Anybody have any suggestions?

-- Bill

[Mike Z.]

Could it be an antivirus (Norton) issue?

"Bill Leavy" wrote:

> .
>

[Bill Leavy]

Hi Mike -

That thought crossed my mind, so I put a 10 second delay after opening
the file to give Norton a chance to scan the file before testing for
ISREADONLY, but it didn't make a difference.

-- Bill

[JayB]

besides the security tab, you must allow the user WRITE access on the
SHARE tab.

[Jürgen Wondzinski]

Does your app work on a different network share?

Can that user create, close, open and modify a textfile at the same location
as your dbfs ?

--

wOOdy
Visual FoxPro Evangelist
Microsoft "Most Valuable Professional" 1996 to 2009

"*��)
�.���.�*��) �.�*�)
(�.��. (�.�` *
..�`.Visual FoxPro: It's magic !
(�.�``��*

[Bill Leavy]

Hi Jay -

Yes, we did this, but the problem still occurs.

-- Bill

[Bill Leavy]

Hi Jurgen -

Not sure what you mean by a different network share, could you
elaborate?

It is on a network share, but I'm not sure what you mean by different.

I will check on the modifying a text file as soon as I can get someone
over there to try it.

-- Bill

[JayB]

you stated that you are working with dbf's and not cursors,
so i took you at your word.

usually i see that "read only" error when i issue a select into cursor
command and forget to specify READWRITE after it

the only way to get that with dbf's other than file permissions is to
open the dbf with a command like
use <tablename> noupd

the only other thing i can think of is if your FAT table is corrupted on
your hard drive for that file, and the OS has a problem reading with
that file. i have seen that cause strange issues.
a CHKDSK could detect that.

[Bill Leavy]

Hi Jay -

I know what you are talking about with the select into cursor, but
that's not happening here, the actual command to open the DBF is...

>>>> USE test

We moved the small test program and test.dbf to a local machine and it
ran fine there, so the issue appears to be between the local machine
and the server.

Don't think it is a corrupted DBF, because it occurs with all DBFs in
the main program as well.

It must be a permissions problem, but all permissions appear to be
correctly set.

There is a readonly attribute on the folder that cannot be removed
through windows. Supposedly it can be removed through a command
prompt with the attrib command, but I tried that and it didn't work.
A Microsoft knowledge base article mentions this, and says that it can
sometimes prevent certain programs from writing to that folder, so
perhaps that is part of the problem. If you're interested, it is
KB326549.

-- Bill

[JayB]

well that is your problem then.
you got to get that read attribute off.
that is why Woody said to create another share.
perhaps that will get set up properly.

try adding that username directly to the sharing and security tab.
for that folder, not at the filelevel.

the network admin there could help with this.

[Olaf Doschke]

Is this win2003 server your first or only server?
Is this network share your first or only share?
If you have a different share for which your test EXE or any EXE writing
into it is working, then you could examine the differences between this
working share and the new nonworking one of course.

Bye, Olaf.

[Bill Leavy]

Hi Jurgen -

The same thing happens with a text file in that directory, the user
cannot save it because it's read only, so it doesn't appear to be a
Fox specific issue. I have the network administrator working on it,
but we're both kind of stumped.

-- Bill

On Wed, 2 Dec 2009 08:59:30 +0100, J�rgen Wondzinski
<jue...@wondzinski.de> wrote:

[Bill Leavy]

Thanks Olaf, I'll check with the Network Administrator tomorrow.

-- Bill

[Bill Leavy]

Thanks Jay, I'll try this tomorrow.

-- Bill

[MikeA]

Sign on as administrator, right click on the folder and go to security and
set the Everyone group to allow for full access to that folder. It's a
network issue, not a VFP problem.

Mike

"Bill Leavy" <ble...@optonline.net> wrote in message
news:q91eh59jpvk75hik2...@4ax.com...

[Bill Leavy]

Hi Jay & Others -

Thanks Jay, Jergen, Olaf and both Mikes for all your help.

The system administrator fixed it today, not sure what he did, but he
created a whole new directory and defined rights from scratch. The
only difference seems to be the presence of an everyone group that I
don't think was there before. Hat tip to Mike on that one.

-- Bill