Hi,

I have a small problem, when I copy the configuration file with the database to another pc and run the application, the first thing the application does
is read an ini file that stores the db location and compare it with the one in the configuration file and if the drive letter or the path are different then it
drops the db and recreate it with the new path read from the ini.  Everything is ok here.  But if the drive of db that is read from the configuration file
does not exists on the pc (In other words there is NO drive E on this PC) then the application can’t drop the db and an error is shown saying "Device
is not ready".  How can this be solved?

Regards,
Abdulaziz Jasser

Abdulaziz,

<< I have a small problem, when I copy the configuration file with the
database to another pc and run the application, the first thing the
application does is read an ini file that stores the db location and compare
it with the one in the configuration file and if the drive letter or the
path are different then it drops the db and recreate it with the new path
read from the ini.  Everything is ok here.  But if the drive of db that is
read from the configuration file
does not exists on the pc (In other words there is NO drive E on this PC)
then the application can’t drop the db and an error is shown saying "Device
is not ready".  How can this be solved? >>

Currently, you can't.  I'll see if I can come up with a workaround for the
next build, however.

--
Tim Young
Elevate Software
www.elevatesoft.com

Abdulaziz,

I did some looking into this issue, and I'm afraid that it can't be solved.
The database must be locked exclusively before it can be dropped, and the
database is locked using the lock file that resides in the database
directory.  It's the act of opening the lock file that causes the problem
that you're seeing.   What you'll need to do to get around this issue is:

1) Create the databases, users, roles, etc. as necessary during installation
instead of copying the configuration file.

2) Change the database paths to something like ..\ that you know will exist
on the destination machine prior to copying the configuration file.

Personally, I would choose 1), which is the reason why the sample
CDCollector application uses this same technique.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim



>I did some looking into this issue, and I'm afraid that it can't be solved.
>The database must be locked exclusively before it can be dropped, and the
>database is locked using the lock file that resides in the database
>directory. It's the act of opening the lock file that causes the problem
>that you're seeing. What you'll need to do to get around this issue is:

I'm a bit baffled here. I understand that you need an exclusive lock prior to deleting the database in case someone else is using it. The lock file resides in the database directory - the database directory doesn't exist so it isn't possible for anyone to be using it so you don't need the lock.

Why not a simple branch in the code

does directory exist
YES - get lock
NO - just remove

Over simplifying things but isn't that possible?

Roy Lambert

<<Why not a simple branch in the code

does directory exist
YES - get lock
NO - just remove

Over simplifying things but isn't that possible?>>

Yes this is a good idea.  Tim, can this be implemented in the next build?  This is a real common situation and need to have a good/simple solution.

Roy,

<< I'm a bit baffled here. I understand that you need an exclusive lock
prior to deleting the database in case someone else is using it. The lock
file resides in the database directory - the database directory doesn't
exist so it isn't possible for anyone to be using it so you don't need the
lock. >>

Good point.  I will do some more checking and see what I can do.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


My other name is Sherlock

Roy Lambert

In know this could break some standards and polices, but just a thought and could be a reality.

UPDATE DATABASES SET PATH = "E:\MtDB" WHERE NAME = "MyDatabase"

I know this could break some standards and polices, but just a thought and later might be a reality.

UPDATE DATABASES SET PATH = "E:\MtDB" WHERE NAME = "MyDatabase"

Abdulaziz,

<< In know this could break some standards and polices, but just a thought
and could be a reality. >>

The metadata tables are read-only and cannot be updated.  DDL statements
update the metadata, and the metadata tables simply reflect these changes.

--
Tim Young
Elevate Software
www.elevatesoft.com