GaryK

Simon,

>>There is lots of stuff that we need to do with each update
>>(prior to each update in fact) that cannot be done by a database

Can you give us an example? That sounds unlikely, you can do virtually anything in TransactSQL via stored proc's.

Cheers

Gary

ex-webby

ok...

Thanks for all the replies.. we could spend hours and hours discussing this though, just trust me that we don't need the databases to synchronise.

(I'm going to explain this bit, but even if there is an answer to this specific bit, there are still countless reasons why it is a) better and b) more possible to do all of this through software.)

One of the reasons is that the data is not reverse engineerable.

You could end up with a record in the penalty table, a changed record in the controltime table, a deleted stage time a change to the cumulative lateness table and an exception report all at once.

These could be generated by a single control time, or by the manual removal of a single stage time. Or by the manual entry of a penalty, or countless other means.

The problem is that we need to trap the actual cause of the change, not the final change, as the clients need to be updated with specific live business rule generated information.

All the best

Simon

IWatkins

Si,

I actually think you should use a clipboard, some paper, a couple of pencils and a stopwatch. Much safer that way and a lot cheaper

Let us know how you get on.

Cheers

Ian

Andrewza

Surely you should be recording penalties in the database and not just updating records to show the effect of a penalty? Then each client just reads the database and uses the penalties stored in the databaseand applies them to the results itself to give a full picture. This might mean a client has to do more work when reading from the database, but it's much simpler and less likely to result in loss of a penalty or corruption

Oops, forgot to add of course this means you can just have the database then handle synchronisation at their level and not worry about the application doing it

[Edited by Andrewza - 8/30/2002 11:41:25 AM]

Crispin

Andrew's right - you'll have no "audit trail" of penalties incurred by driver/stage either if you just lop them off the end time....

re MySQL vs SQL Server, no overkill at all IMHO, also the cost of ownership for SQL Server vs Oracle is a lot lower

hth

GaryK

Simon,

>>(I'm going to explain this bit, but even if there is an answer to this specific bit, there are still countless reasons why it is a) better and b) more possible to do all of this through software.)

If scalabilty and reliability is your main concern then putting business logic in the presentation layer (UI) is the worst move you can make, all of what you said is doable if like other people have mentioned you just create an audit trail, dont *physically* delete records just create datetime columns with create/update/delete dates, just a suggestion you are closest to the data so know it more intimately than anyone else here.

Good Luck

Gary