I had to take my car in for a service/MOT to Arnold Clark in Inverness - about 95 miles away. I decided to resurrect my old notebook and wiped it, reinstalled XP, installed the service packs, installed D2006, ElevateDB etc.

When I got there I adjusted a few file paths so I could work and then discovered that all the tables in my app had become readonly.

Gobsmacked I checked the file properties and found while the table files didn't have readonly checked the folder was grayed out. I thought "fine I know how to fix that" Cleared readonly, clicked apply, selected subfolders, clicked OK. Checked the properties and its still grayed out. Nothing I can do to alter it!

Got home and checked on my Vista PC and its the same. However, on this machine the tables aren't read only.


HELP

Roy Lambert

I should also have said that I tried 1) copying the tables to a new folder - still readonly 2) createing a new session/database/table and it ended up readonly.

I did have success creating a memory database and a table in there that I can access

Roy Lambert

Roy,

<< Gobsmacked I checked the file properties and found while the table files
didn't have readonly checked the folder was grayed out. I thought "fine I
know how to fix that" Cleared readonly, clicked apply, selected subfolders,
clicked OK. Checked the properties and its still grayed out. Nothing I can
do to alter it!

Got home and checked on my Vista PC and its the same. However, on this
machine the tables aren't read only. >>

So, the attributes of the individual files are normal, but the containing
folder is still marked as read-only ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy

> Gobsmacked I checked the file properties and found while the table files
didn't have readonly checked the folder was grayed out. I thought "fine I
know how to fix that" Cleared readonly, clicked apply, selected subfolders,
clicked OK. Checked the properties and its still grayed out. Nothing I can
do to alter it!

The read only flag on folders in XP seems to be a bit meaningless.

You could try switching off simple file sharing (if it is on) and check the
security settings for he folder/files.

John

Tim

>So, the attributes of the individual files are normal, but the containing
>folder is still marked as read-only ?

Not quite - it has the grayed check mark which "should" mean that some things below it are read only. However I can't find them

I copied over DBSys this morning and it will happily create a table AND allow me to edit it. I hate to say it but it looks like a definite issue with ElevateDB, probably caused by coping over the LAN from a Vista to an XP machine. What does it use to decide if a table is read only? Or have you built in a hidden "annoy Roy by pretending his hard drive is a DVD" switch?

The current state of my investigations is:

1. I can copy and edit DBISAM tables from another Vista PC
2. I can create a new database, reverse engineer the ElevateDB tables (excluding data) and edit those (misremembered after the drive back yesterday)
3. I can delete the data files and EDBManager will recreate them but again I can't edit them
4. Nothing I can do will allow me to edit the ElevateDB tables as copied from the Vista PC (just tried again)

Its not just EDBManager because my app also refuses me permission to edit them. I'm logged onto Windows as Administrator. ElevateDB Administrator has full permission to do things to the tables (in EDBManager I log in as Administrator and my users in the app have the same role).

I have tried individually checking / altering properties on tables, altering properties on folders at various levels in the path to the tables, turning on and off sharing but no joy.

Any suggestions as to anything I can check out / try. Its not a particular problem, but its annoying.

Roy Lambert

Tim / Anyone

The latest experiments - copy from Vista PC and I can't alter the tables (but can delete and if I do so ElevateDB will recreate) but if I use my conversion tool for the app which deletes and creates the tables from the DBISAM originals I can, even though its in the same directory.

Conclusion so far is that copying over my LAN from Vista is carrying over some security flag that I can't see in XP and this is being used somehow by ElevateDB but not by the OS, but weirdly whatever this flag is works OK on the Vista box.

On both PC's I'm set up as the only user, same name etc and both with administrator privileges.

I'm totally flummoxed.



Roy Lambert

Roy,

<< Conclusion so far is that copying over my LAN from Vista is carrying over
some security flag that I can't see in XP and this is being used somehow by
ElevateDB but not by the OS, but weirdly whatever this flag is works OK on
the Vista box. >>

Well, the only thing ElevateDB does is the same thing that DBISAM does - it
tries to open the table files in read-write mode.  If it fails on any of
them, then it tries to open the table files in read-only mode instead.
That's it - that's the extent of EDB's involvement with security
restrictions.  If you have an issue with the tables being treated as
read-only, then it is coming from the OS.  Of course, I couldn't tell you
where without actually looking at your files myself.

Did you check the catalog file in the database directory to make sure that
it is not read-only ?  What about the hidden EDB lock file
(edbdatabase.edblck) in the database directory ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

I just deleted the folder on the XP machine (for the third time) copied the stuff across and I can edit the tables. The only thing I did differently is this time I remembered to change the database path on the XP machine before trying to access the tables (it changes from E: to C

All I can say is

Computer gremlins rule OK!

Roy Lambert

Roy,

<< I just deleted the folder on the XP machine (for the third time) copied
the stuff across and I can edit the tables. The only thing I did differently
is this time I remembered to change the database path on the XP machine
before trying to access the tables (it changes from E: to C >>

What "database path" are you referring to ?  The one defined for the
database in EDB's config file ?  If you had the database path pointing to a
different location than what was necessary, then I'm not surprised that the
results weren't what you expected.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


><< I just deleted the folder on the XP machine (for the third time) copied
>the stuff across and I can edit the tables. The only thing I did differently
>is this time I remembered to change the database path on the XP machine
>before trying to access the tables (it changes from E: to C >>
>
>What "database path" are you referring to ? The one defined for the
>database in EDB's config file ? If you had the database path pointing to a
>different location than what was necessary, then I'm not surprised that the
>results weren't what you expected.

Yup - the equivalent of ALTER DATABASE xxx PATH yyyy

But obviously once I'd realised I hadn't altered the path I did so otherwise I wouldn't have been able to see the tables let alone find out they were readonly. So I'll match your and up the bid to <vbg>


The only difference is this latest time I altered the path before trying to open the database rather than after.


I'll wipe it and do another transfer in the morning and test out my theory.

Roy Lambert