Another DB question

[Jan Schenkel]

--- Klaus Major <klaus at major-k.de> wrote:
> Hi all,
> 
> although I did not receive a response to my first DB
> questions,
> I dare to ask another question :-)
> 
> Is it possible to directly "search" in the data of a
> db cursor?
> Or will on have to use a repeat loop through all the
> data in a cursor
> to find the desired data? Know what I mean?
> 
> Background:
> When the user adds/inserts or updates a record, the
> current cursor is  
> not
> "up to date" anymore and one has to create a new one
> that reflects  
> these changes
> 
> And of course it is "good style" to display the SAME
> data to the user  
> after that action
> and not the first record of the new cursor.
> 
> 
> Regards
> 
> Klaus Major
> 

Hi Klaus,

It's a very old problem inherent to the SQL query
model with database-independent front-ends: how to
ensure that all clients have up-to-date data.

And this gets even messier when you're taking
transactions into account: changes to the database
shouldn't be visible to another user until they have
completed and the entire transaction is committed.
That's why, in most modern databases, cursors are a
'snapshot' of the records that matched your criteria
at the time of query execution.

Some databases offer 'live' cursors that will fetch
the latest information from the database when you
'move' to a record in the result set.
That helps but still leaves you in the cold when
you're looking at a record that gets updated by
another user while you're idle. Of course, you could
use a 'send in x seconds' refresh loop.

The way FileMaker Pro and other database-tied
front-ends do this, is by pushing update information
from the database server to all the clients, based on
some sort of publish-subscribe scheme.

Jan Schenkel.

Quartam Reports & PDF Library for Revolution
<http://www.quartam.com>

=====
"As we grow older, we grow both wiser and more foolish at the same time."  (La Rochefoucauld)