Hi Robin

You can use a timestamp to check to see if the row has changed since
selecting it rather than checking each of the columns individually.

John

"Robin Tucker" <idontwanttobespammedanymore@reallyidont.com> wrote in message news:<cohk2t$dio$1$8302bc10@news.demon.co.uk>...
> 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
> >> >>
> >> >
> >> >