SqlExecute and valentina database locks

[Thorsten Hohage]

Hi Vansh,

On 2009-01-02, at 19:49, Vansh Singh wrote:
> I don't know much about how Valentina locks a database while it is  
> under
> use.
We must make a big and bold difference between locking a database FILE  
and e.g. a table in the database. These are totally different beasts!

When you open a DB locally using a "OpenDatabase" command to read a  
file from disc, then this file is locked and (perhaps depending on  
your OS and some other reasons) you're able to use this file as read  
only or not at all from a second app, and it doesn't matter here, if  
the two apps are running on one machine or on different in a network.


> I have an application that is usually deployed on a network for
> multiple people to have access to it within the network. There is
> another 'updater' application that updates the database of the main
> application. The main program and the updater program could be likely
> running on 2 different computers.
Just to make it clear - are you talking about a VServer (Embedded or  
Office) or about using a file on a shared volume???

I would hope, strongly suggest and assume for now, that you're using a  
VServer ...


> I want to make sure that the application updater is stopped (and  
> user is
> displayed a message about it) when the main program is running  
> anywhere
> on the network. So that's where I begin to think about Valentina  
> locking
> the database. ................

You should use a Cursor and use a ReadWrite-LockLevel. Then you can  
check if this table is locked or you'll become a table locked  
exception, if another app try to write, too.

So everything like you expect.

BUT keep in mind, there are several situations you need to deal with,  
NOW! E.g. what happened if the app is setting a lock and then goes  
wild, crashes, ...? The user opens a record for update, decide to have  
lunch right now, leaves his office and lock the door, ....

So using locks is perhaps not as easy as it might appear on the first  
glance.


> You sure don't want to update a database on a
> desktop app while it is under use.


Being "lazy", the last updates overwrite the updates before - bad  
guy ;-)

Or

Caching the original data and then checking before updating, if the  
record is changed and then ask the user what to do ... real  
complicated sometimes and guess what ... yes, 9x% of the users believe  
they are always right and decide to overwrite, with out carefully  
reading the dialog, so we're back to version 1 ... one difference the  
user is the bad guy :-)))


regards,

Thorsten Hohage
-- 

Valentina Technology Evangelist
generic objects  GmbH - Leiter Solution Center Nord