Louis,

> This is exactly what a CDS does (actually the Provider does it, but...).
>
> No need to roll your own anymore. Yeah!

Not exactly - this project was started with D2, there wasn't a CDS then,
and it still works great in D5... (or D6 for that matter).

Besides that, when we had an object, for example TCustomer, it had
properties, could be a descendant and could be loaded from multiple
tables as the object <-> relational mapping wasn't one on one (which,
in most cases isn't a good thing).

It was _much_ more advanced and designed for different purposes than
CDS.

So, hell yeah - there still is a need to roll your own if you want to work
object oriented (not only in programming, but also in business modelling).


Just my 2Eurocents...

Martijn Tonies
InterBase Workbench - the developer tool for InterBase and Firebird
http://www.interbaseworkbench.com

Upscene Productions
http://www.upscene.com

"This is an object-oriented system.
If we change anything, the users object."

> Louis Kleiman
> SSTMS, Inc.
>
>
> Hi,
>
> > Doug Chamberlin wrote:
> > > Actually a much better way is
> > > Start trans
> > > Read record
> > > Commit
> > > Let user edit record taking all the time they want.
> > > When they save:
> > > Start trans
> > > Write updates
> > > Commit
> >
> > But you'll have to worry about whether you are updating the same

database

> > (as you read from) - you have to control every record that can be

affected

> > by the inserts/updates/deletes. Not impossible, but a chore.
> > I use the timer approach (with commit or rollback), but this isn't

without

> > problems. I've found users returning from lunch and seeing their work

has

> > been rejected (rollback) having assumed that whatever they were

editing

> > (either in a grid or a separate form) has automagically been completed

for

> > them! Result: the record was never entered into the database.
>
> We once created a system that updated only the modified column in this

way:

>
> update mytable set changecol1 = newvalue1, changecol2 = newvalue2
> where idcolumn = idvalue and changecol1 = oldvalue1 and changecol2 =
> oldvalue2
>
> If the update returned '0 rows affected' we would know there was a

'lock'

> error.
>
> Worked great.