To me, this sounds like it might be a place for either a UDF, or the use
of the embedded engine.

On Tue, 2005-07-12 at 00:45 +0000, Adam wrote:
> --- In firebird-support@yahoogroups.com, <buppcpp@y...> wrote:
> > >
> > > I actually think it would be a bad thing for SPs to support such
> a
> > > feature. I mean imagine if you thought you could rollback your
> > > transaction, but one of the SPs you relied on had committed it.
> >
> > That's you just not undertsnding your database design, it's not a
> fault of
> > the database.
> >
> > >The next query you tried to run would fail because there was no
> transaction
> >
> > > to be run. You would also lose your "snapshot" of the database.
> >
> > SQL Server supports it, and after you do a commit or rollback, it
> > automatically starts you with a new (implicit) transaction.
> >
> > So I still don't see a problem with commits in SP.
> >
> >
> > Thanks
> > Bupp
>
> Actually Bupp I see it as you not understanding who controls the
> transaction. Does SQL Server have a MGA yet? Will it still support SP
> commits when it does is probably a more interesting question for you.
>
> Getting to the database design issue. No I do not understand my
> entire database design to the T. There are too many entities for me
> to remember each, but because of good practices and naming
> conventions, I do not need a guided tour to find anything.
>
> Now imagine if to solve a problem in one part of the system a
> developer changed a procedure to commit itself after each run. This
> would cause atomicity and isolation issues elsewhere in the system,
> and these probably would not be caught by test cases which tend to be
> isolated anyway.
>
> Please listen to what I have said before.
>
> I agree it would be a powerful feature to allow you to call something
> that looked and felt like a stored procedure. It could have the same
> language even, and within this script you could create a transaction,
> and rollback or commit it at will. There is a need for something to
> be "close enough" to the database engine that fetch time is not
> exagerated by network congestion etc, but it still needs to be
> a "client" to some degree so we don't throw out the baby with the
> bathwater.
>
> I also agree with Si that you could even introduce the ability to
> create a transaction within a SP that you could rollback or commit at
> will without contradicting the way it works, but my client program's
> transaction is not owned by the procedure, and the procedure has no
> right to commit it or rollback it. I am in the middle of an atomic
> operation.
>
> Adam
>
>
>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://firebird.sourceforge.net and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Yahoo! Groups Links
>
>
>
>
>
>