Quoting DeBug <[EMAIL PROTECTED]>: > >>[MySQL] > >>1: START TRANSACTION > >>2: WITHDRAW $50 from account 32146. > >>3: DEPOSIT $50 into account 12345. > >>4: LOG transfer (date/time/teller/etc...) for auditing. > >>5: COMMIT TRANSACTION > > DK> It depends why step 3 failed. > DK> If you want to rollback the transaction to the beginning on any error, > DK> you simply use an 'on error' statement in VB to trap the error, and send > > DK> a rollback command when the error is detected. > And what if the server lost connection with client computer ? > there must be automatic rollback after certain 'time-out' period > > Data integrity logic should be ensured by client application (when to > call 'start transaction' and when to call 'commit'), the server task is to > ensure that logic - i.e. that at any given moment users see the > database in integrity state and not at some point within transaction > processing. > If user has not commited transaction the database integrity state is > still at the point before start transaction was called.
My $0.02 I have to disagree - especially when money is involved. To have the client define, check data integrity, and manipulate data in the database is just asking for trouble. Call me paranoid, but to trust a client in a non-secure environment to directly access and manipulate the database is just asking for a reverse-engineered attack against the database where the data will be compromised. At the very least, you are sending out database connectivity information out with the client that can be stolen and used to access the database. Given the means and the business necessity, I feel that having some sort of middleware on a secured server to validate data and communicate with the database is a much more secure methodology. This is a trivial piece of middleware to write, but can add a much needed layer of security to transactions. Let the secure server hosted middleware host the database connections and let the client talk to the middleware. > > Not user but server is responsible for rolling back not commited > transactions, user can only help relief the server from major part of this > problem by trying to > rollback as many failed transactions as he can. however user cannot be > responsible for rolling back all the transactions > > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
