| Subject | Re: Inserting 100's of thousands from a SP |
|---|---|
| Author | Adam |
| Post date | 2005-07-12T00:45:23Z |
--- In firebird-support@yahoogroups.com, <buppcpp@y...> wrote:
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
> >a
> > I actually think it would be a bad thing for SPs to support such
> > feature. I mean imagine if you thought you could rollback yourfault of
> > 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
> the database.transaction
>
> >The next query you tried to run would fail because there was no
>Actually Bupp I see it as you not understanding who controls the
> > 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
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