Tim

Just confirmed my idea:

1. Copy data across
2. Open EDBManager
3. Open session (TfR)
4. Try and open database (NLH) WITHOUT altering path - error
5. Alter path for NLH
6. Open database NLH
7. Open tables - they are read only!
8. Create new database (xxx) pointing to the tables
9. Open database xxx
10. Open tables - I can alter them

So I now have two databases - 1 read only and the other alterable - both using the same tables.


Roy Lambert

Roy,

<< So I now have two databases - 1 read only and the other alterable - both
using the same tables. >>

Are you sure about this ?  There is nothing in the database definition that
affects the read-only status of the tables, so there should be nothing
special about the second database definition.

What you're saying is that you have two databases with the exact same path
that points to the exact same tables, and one of them can modify the tables
while the other cannot ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

><< So I now have two databases - 1 read only and the other alterable - both
>using the same tables. >>
>
>Are you sure about this ? There is nothing in the database definition that
>affects the read-only status of the tables, so there should be nothing
>special about the second database definition.

If I wasn't sure I wouldn't be posting

>What you're saying is that you have two databases with the exact same path
>that points to the exact same tables, and one of them can modify the tables
>while the other cannot ?

I also have difficulty believing this.

I've just tried another experiment, this time without copying tables, and its one you can try yourself.

1. pick a session in EDBManager which has databases and tables under it.
2. Create a new session with the path almost pointing to it. Keep the directory structure correct but have a different disk identifier, one that soen not and can not exist on your machine - eg my real path is E:\HH Dev\TfR\NLH so I used Q:\HH Dev\TfR\NLH (I have no Q drive)
3. Try and open a table under the this database you get the following error

---------------------------
ElevateDB Manager
---------------------------
ElevateDB Error #600 File manager error (Cannot create file q:\hh dev\tfr\nlh\EDBDatabase.EDBCat (OS Error: The system cannot find the path specified.
))
---------------------------
OK  
---------------------------

4. Alter the database path to the real one
5. Open one of the tables and its read only


Will someone please try this and confirm I'm not totally off my rocker.

Roy Lambert

Roy,

<< I've just tried another experiment, this time without copying tables, and
its one you can try yourself. >>

<< 1. pick a session in EDBManager which has databases and tables under it.
2. Create a new session with the path almost pointing to it. Keep the
directory structure correct but have a different disk identifier, one that
soen not and can not exist on your machine - eg my real path is E:\HH
Dev\TfR\NLH so I used Q:\HH Dev\TfR\NLH (I have no Q drive) >>

Create a new *session*, or a new *database*, or both ?  If you create a new
session with an invalid config path, then it is impossible to try and open a
table.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>Create a new *session*, or a new *database*, or both ? If you create a new
>session with an invalid config path, then it is impossible to try and open a
>table.

With the latest test existing session new database.

Roy Lambert

Roy,

<< With the latest test existing session new database. >>

Okay, I've reproduced this.  The issue is that once you try to open a
database in a non-existent location, the lock manager essentially marks the
database as read-only since the lock file cannot be written.  To resolve the
issue, just close and re-open the session.

I'll see what I can do to correct this.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>Okay, I've reproduced this. The issue is that once you try to open a
>database in a non-existent location, the lock manager essentially marks the
>database as read-only since the lock file cannot be written. To resolve the
>issue, just close and re-open the session.

Not in EDBManager - I've just tried it. Also if "just close and re-open the session" works how is it persisting between closing and reopening EDBManager?

>I'll see what I can do to correct this.

Should you correct it or build it in as a feature

Roy Lambert

Roy,

<< Not in EDBManager - I've just tried it. Also if "just close and re-open
the session" works how is it persisting between closing and reopening
EDBManager? >>

Ahh, yes, sorry - I realized after I posted that response that the second
alter is going to permanently set the read-only flag for the database,
requiring a DROP DATABASE KEEP CONTENTS/CREATE DATABASE cycle to fix the
issue.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


On a serious basis is this worth having an option for and keeping as a feature, without the need to try and access the database with a duff path?

Roy Lambert

Roy,

<< On a serious basis is this worth having an option for and keeping as a
feature, without the need to try and access the database with a duff path?
>>

You mean marking a database as read-only ?  If so, then yes, this is on the
list along with the ability to mark individual tables as read-only.  The
functionality has actually been in EDB since day, but hasn't been exposed.

--
Tim Young
Elevate Software
www.elevatesoft.com