Re: Technique for concurrent access? Although I am using transaction processing at present and I understand that
anything in the brackets of the transaction is "unitary" in nature and
either will or will not be applied in its entirety, there still remains the
issue of updating the other clients when a change has taken place in the
database. I assume there is no "call back mechanism" I can use to keep the
clients all synchronised? ie. I won't know when another client has accessed
the database unless I perform some kind of poll and update myself if they
have.
"John Bell" <jbellnewsposts@hotmail.com> wrote in message
news:41a79cc9$0$11899$afc38c87@news.easynet.co.uk. ..
> Hi
>
> You don't say how your application will not cope with multiple users. SQL
> server is a muti-user environment therefore you may be better writing
> transaction handling into your application than a single-user "cludge".
>
> If you use the table based method you will almost invariably have to also
> write a reset option.
> Alternatively you may want to do this within the application for example
> using as using a mutex in .NET or the application object in ASP.
>
> John
>
> "Robin Tucker" <idontwanttobespammedanymore@reallyidont.com> wrote in
> message news:co7dv2$j77$1$8300dec7@news.demon.co.uk...
>> I've been asked to turn our single-user database system into a multi-user
>> system. At present, each user has a copy of the MSDE on their desktop
>> machine and uses our program to access it. In future, we would like to
>> centralise our MSDE instance and allow multiple users to access it. In
>> order to facilitate this, we are going to only allow one user write
>> access to the system at a time (I know, its a kludge, but the system was
>> never designed for multiple users in the first place).
>>
>> I have a single, simple question this being the case: can I update a
>> single "read-only" bit field in a table of the database in order to flag
>> to other users that the system is in read-only mode in a way that avoids
>> concurrency issues? ie. does an "UPDATE" query lock and unlock? ( I
>> suspect the answer is yes! ). If anyone else has experience of these
>> things, I would also appreciate some tips on how best to proceed.
>>
>> Thanks
>>
>>
>> Robin
>>
>
> |