Ok, thanks for your help. Useful information for my manager at least

This isn't a real-time system. Actually, its a central repository for
images and associated data. I've implemented a tree structure, similar to a
file system inside the database. All access goes through a single module,
calling stored procedures, so I can put "locks" in no problem. I think my
solution will be to allow potential overwrites, coupled with warnings that
the database needs a refresh if, for example, nodes are deleted when another
user attempts to access.

Thanks again.


"John Bell" <jbellnewsposts@hotmail.com> wrote in message
news:3b81e6a.0411292331.44d6533e@posting.google.co m...
> Hi
>
> There is not automatic call back mechanism for this, so you would run
> the risk of overwriting someone else's changes. It sounds like you are
> wanting a real-time system which is not really what a database is
> designed for and it is tricky to do that in any client.
>
> You could force a refresh periodically, although this may be annoying
> to a user if they take a long time. Factors will be how volatile the
> data is, how many users you have and if the changes made are likely to
> be significant.
>
> Check out Notification Services it may be useful.
>
> John
> "Robin Tucker" <idontwanttobespammedanymore@reallyidont.com> wrote in
> message news:<cof6e0$rj2$1$8300dec7@news.demon.co.uk>...
>> 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
>> >>
>> >
>> >