Re: RFC on Fitch & Mather Sample

Steve,

Thanks for your response.

>
>1. Server-side locks are held until a transaction completes, and
interaction
>between client and server during a batch will usually cause a transaction
to
>remain open for many times longer than it would if executed completely on
>the server.
>
>

Yes, but an online application requires interaction inside a transaction sometimes.

>
>2. A client may experience an error between the start and finish of the
>transaction that is too severe (or not handled well enough) to allow the
>transaction to be completed by the client without intervention. This may
>leave locks open that can stop other users from continuing to work. If the
>task has to be cancelled from the server, a partially completed transaction
>may be rolled forward, not back leaving data in an inconsistent state.
>

I think the client's design is awkward in such case. IMO 3GL languges are more powerful for errror handling then pure T-SQL. I like "try - catch" more then testing @@ERROR variable after every T-SQL statement.

BTW: Is it possible to handle RAISERROR in a pure T-SQL somehow? What about the deadlocks?

I think that using single database with one and only client is rare. We can see solutions which provide users with more applications to access shared database.
It is very hard to maintain bulk of procedures and triggers and make it suitable for every application (sometimes written by different suppliers).
Portability and integration can hurt as well.

However I was interested in something else. The sample presents using triggers as an alternative to DRI. Because of missing PRE-triggers (before) in MS SQL, rollbacks had to be put into these post-triggers.

I am interested in what advantages PRE-triggers can provide as an alternative to DRI in comparing with standard DRI and POST-triggers (after)
and I am also curious of ODBMS features (ORACLE) - Whether OO paradigm allows using the base (abstract) entity with "D" and "IU" trigger templates (methods?) and deriving other entities providing better maintainability and using the same concept.

DB2/400 might use different approaches. Maybe more elegent...

--
Thank you for keeping >anti-spam< habit: not including my address in your reply. Received on Fri Jun 18 1999 - 03:51:57 CDT