> > I think I understand and your mod's to my update statement make sense.
> > So what we are looking for is NOT a question about concurrency? This is
> > sort of a "dirty write" or the "lost updates" problem. One update over
> > writes a prior update.
>
> To me it is a concurrency issue: 2 clients updating the same record "at the
> same time" (which really means the read/edit/write processes overlap.)
>
> > OK let's take the problem from the MsSQL side:
> > 1. I think the _mssql (works like the ado) will issue an exception when
> > one or more records in your record set has been changed. However, I
> > think this will not apply to Dabo's way of dealing with a cursor.
> >
> > 2. So that leaves us with the way I do it. I use the rowversion (use to
> > be the timestamp). The rowversion works as long as you are using only
> > one database. Remember Microsoft guarantees that the number will be
> > unique.
>
> In VFP terms: WhereType = 4 - Key and TimeStamp.
>
> Why "as long as you are using only one database" ?
>
> > OK let's take the Postgres way:
> >
> > 1. Again the psycopg.py would raise an exception (depends on the setting
> > of the "set transaction isolation" settting). And of course should be
> > handled in code. Again most likely will not work with Dabo cursors.
> >
> > 2. My way is to read the xmax or xmin fields. "Where xmin=myxmin " or
> > xmax = null.
> >
> > I would think Sybase works as does MsSQL. But I know nothing about
> > MySQL, SQLite, Oracle (some day in the future?) or FireBird. The best
> > guess is they have something to handle "lost updates".
> >
> > So I wonder if adding 98 fields to the where is the best generic way of
> > dealing with "lost updates". Maybe a better solution would be to add a
> > way to set the where clause to include the each database engines unique
> > way of dealing with "lost updates" . Similar to the way we deal with the
> > "limit" clauses of the database engines.
>
> I think you are assuming there is something wrong with 98 fields in the
> where clause.
>
> Given that I don't see a problem, I think it is better than engine specific
> code.
>
> Carl K
>
>
> _______________________________________________
> Post Messages to: [email protected]
> Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
Rowversion is unique only within a single database. The number can be
repeated in another database.
It's not that I think something is wrong with 98 where fields but that I think
a general way to add database engine features or use them would be a better
solution since all database engines have them.
Lets take the example of a Money type. At least two database engines (MS and
Postgres) have a similar type. But each is handled differently. If we had a
general way to handle database features it could be used to handle the
differences. VFP for example handles such issues via the connection (ADO,
ODBC) or driver.
Another example might be the way cascading works. There are many. I'll list
a few of the unique features that Dabo does not take advanage of:
1. Use of regular expressions, SET , SHOW , and RESET are features unique to
POSTGRESQL.
2. OIDs, sequences , and SERIAL are unique features of POSTGRESQL.
3. FROM in UPDATE is a unique feature of POSTGRESQL. Some databases support
the creation of tables by SELECT.
4. Most databases support only a few of the many data types, functions, and
operators included in POSTGRESQL. Casting using :: is nonstandard. Arrays
are a unique features of POSTGRESQL. Large objects are implemented
differently by other database systems.
5. CLUSTER , VACUUM , and EXPLAIN are features unique to POSTGRESQL.
6. LIMIT is implemented by a few other database systems.
7. Inheritance, RULES , LISTEN , and NOTIFY are features unique to
POSTGRESQL.
8. COPY is a unique feature of POSTGRESQL.
9. All of the programming interfaces except Java are implemented differently
by other database systems.
10. Server-side functions and triggers are implemented differently by other
database systems.
11. Using C to enhance the database is a unique POSTGRESQL feature.
As you can see Postgres is different and currently Dabo does not have a
standard way of using them - unless you consider handing coding as the only
way.
BTW I'll have to admit I don't use most of these - but I have used "FROM" in
an update statement and used inheritance. Played with LISTEN and NOTIFY.
And Yea some are just silly ways of dealing with stuff - like SERIAL is
nothing more than an automatic sequence.
Also I have to admit that I could add the features to the dbPostgres.py and
just make them available to the programmer.
--
John Fabiani
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
