Hi,

I need to do some maintenance operations on the database and while I am doing that I need to prevent the other users from login to the database.
How to lock the whole database in a way that works with C/S, file sharing, and single user modes?  

Regards,
Abdulaziz Jasser

Abdulaziz,

<< I need to do some maintenance operations on the database and while I am
doing that I need to prevent the other users from login to the database.
How to lock the whole database in a way that works with C/S, file sharing,
and single user modes?  >>

Just use the TEDBDatabase.StartTransaction method:

http://www.elevatesoft.com/edb1d7_tedbdatabase_starttransaction.htm

--
Tim Young
Elevate Software
www.elevatesoft.com

<<Just use the TEDBDatabase.StartTransaction method:

http://www.elevatesoft.com/edb1d7_tedbdatabase_starttransaction.htm>>

Is there another way of doing this?  I will be doing some ALTERING to the database and I am looking for a better way
like "EDBDatabase.LockDatabase" since the other users will try to test the db to see if it is busy or not when the application starts using this method.

Abdulaziz,

<< Is there another way of doing this?  I will be doing some ALTERING to the
database and I am looking for a better way like "EDBDatabase.LockDatabase"
since the other users will try to test the db to see if it is busy or not
when the application starts using this method. >>

The only other way would be via an exclusive open on the database.  However,
that functionality is not currently surfaced in the TEDBDatabase component.

--
Tim Young
Elevate Software
www.elevatesoft.com

Abdulaziz


If its only your apps that will access the tables then you can do something. If you don't already get users to log in then do so. Have a users table and when you want to do something try and open it exclusively. That stops people logging in. Getting them to log out is different


Roy Lambert

Roy,

<<If its only your apps that will access the tables then you can do something. If you don't already get users to log in then do so. Have a users table
and when you want to do something try and open it exclusively. That stops people logging in. Getting them to log out is different >

With DBISAM 3 I used semaphores to do that but EDB does not support semaphores.  I will try your suggestion.  Thanks...

>Roy,
>
><<If its only your apps that will access the tables then you can do something. If you don't already get users to log in then do so. Have a users table
>and when you want to do something try and open it exclusively. That stops people logging in. Getting them to log out is different >
>
>With DBISAM 3 I used semaphores to do that but EDB does not support semaphores.  I will try your suggestion.  Thanks...

Yes, and the semaphores were table based, not database based.  You
could employ something similar using a memory based database - create
it if it doesn't exist and create tables with the database.  One such
table could have two columns, TABLENAME and LOCKED.  You could then
add a row for any table(s) you wanted to lock and you could also add a
single row for the entire database (e.g. TABLENAME = DATABASE).

Semaphores were nice but were limited in the number of semaphore locks
that could be placed and were limited to tables.  In-Memory databases
and tables can provide much more functionality and flexibility.

- Bill

Bill,

<<Yes, and the semaphores were table based, not database based.  You
could employ something similar using a memory based database - create
it if it doesn't exist and create tables with the database.  One such
table could have two columns, TABLENAME and LOCKED.  You could then
add a row for any table(s) you wanted to lock and you could also add a
single row for the entire database (e.g. TABLENAME = DATABASE).

Semaphores were nice but were limited in the number of semaphore locks
that could be placed and were limited to tables.  In-Memory databases
and tables can provide much more functionality and flexibility.>>

Thanks for comment.  However, they way I was doing it with DBISAM is to create one semaphore in one table to signal the other sessions to logout
and prevent new sessions from login.  That was done through the application level using one table with many semaphores for signaling.  Right now I
have a couple of ideas to do that, but I have to test all of them and choose one.

>Bill,
>
><<Yes, and the semaphores were table based, not database based.  You
>could employ something similar using a memory based database - create
>it if it doesn't exist and create tables with the database.  One such
>table could have two columns, TABLENAME and LOCKED.  You could then
>add a row for any table(s) you wanted to lock and you could also add a
>single row for the entire database (e.g. TABLENAME = DATABASE).
>
>Semaphores were nice but were limited in the number of semaphore locks
>that could be placed and were limited to tables.  In-Memory databases
>and tables can provide much more functionality and flexibility.>>
>
>Thanks for comment.  However, they way I was doing it with DBISAM is to create one semaphore in one table to signal the other sessions to logout
>and prevent new sessions from login.  That was done through the application level using one table with many semaphores for signaling.  Right now I
>have a couple of ideas to do that, but I have to test all of them and choose one.

You can still use an inmemory table the same exact way.  DBISAM
allowed up to 1024 semaphores locks per table.  If you use a single
table to manage all your locks, then create a single in memory table
with 1024 rows and two columns: SLOT (numbered 1 to 1024) and LOCKED.
Then write your own LockSemaphore and UnlockSemaphores functions
passing the Slot number you want locked.  Your function would look to
see if the Slot was already locked and return false indicating that
the lock failed, otherwise it would set the value to lock and return
true.

If you use Semaphores now in a DISAM application, the one shortcoming
of the Semaphore is that the only way to determine if a lock is set it
to try to lock it and if it fails the slot was locked.  If you were
only wanting to check the lock, then you would need to immediately
unlock it if it was locked by your process.   This could present a
problem where the slot was not actually in a true "locked" state and
was merely temporaily locked for testing and thus gives a false
positive.

Using the in memory table, you could also add a function to see it a
particular slot is locked by simply testing the value of the LOCKED
column for that slot versus attempting to lock and then unlock the
slot.

There are many options for you to use but if you are converting code
from DBISAM to EDB and use semaphores, this may be the simplist
solution for EDB that works nearly identically to DBISAM.

Bill,

<< You can still use an inmemory table the same exact way. >>

You would need to use a disk-based table if you want it to be accessible by
all users.  An in-memory table will only be visible to the current process
in which it resides.

--
Tim Young
Elevate Software
www.elevatesoft.com