Getting this on a new system just into beta.

Here is the scenario...

Retail type application... in only one location... small location, 4 POS
clients, one back office app, 1 communication client sending changed
data back to through a middle tier app at a remote location.

FB 1.5 Superserver
plenty of hardware on XP in all cases at beta site.

POS app collects information about items, pmt, etc in in-memory
structures from information queried from the db . then, in a separate
transaction component and all at once, writes the transaction row,
transaction detail rows for line items, payment rows, (all related to
the transaction table). The transaction detail rows have a trigger on
insert update and delete (although only inserts are done) that update a
total in the transaction record. This in turn, updates a record in a
table for the "Cash drawer (till)" via a trigger.

after 2 weeks of no problems, today, had to stations get repeated Lock
conflict errors.

My concern, is that while there is no possible way for two stations to
be updating the same "row" at the same time, that the lock conflict
occurs on a page level. Am I correct in this conclusion... that even
though no two records could be updated by two different users, that the
lock conflict is still possible if the two distinct rows happen to be on
the same page?

If so, making page size smaller would reduce but not eliminate this,
correct? (not to mention the other down sides).

The only clear solution would be to total things up at a set point in
time...

I don't have a problem doing this with the transact to trigger till, but
the transdetail to transact seems extreme... I could total it up outside
of the database, I suppose, (in the app, not in triggers) but would
prefer this to be in the database as a business rule to eliminate the
possibility of some other process breaking this business rule.

Ideas?


Thanks
Mitchell peek