Re: transaction with unknown nbr of commands
- From: "Mary Chipman [MSFT]" <mchip@xxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 02 Sep 2005 16:34:55 -0400
If you really need all of those updates to commit/rollback as a single
unit of work, then you need to pass all of the information to your
sproc in input parameters. One technique I have used in the past is to
package up the values in delimited strings, and then parse the strings
into a temp table or table variable in the stored procedure code. This
is very labor-intensive in T-SQL, and works best if you only have to
deal with numbers, not strings, where you have the added hassle of
parsing special characters, delimiters, etc.
When you update from a DataSet/DataAdapter, you're doing one row at a
time, with each row being a separate transaction, and there is always
the possibility that some rows would commit and others not. You can
get error information back as to which rows did not commit, but you
can't undo the rows that have already committed.
--Mary
On Tue, 30 Aug 2005 13:37:03 -0700, Alex S Moore
<AlexSMoore@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
>
>"Mary Chipman [MSFT]" wrote:
>
>> For maximum efficiency and scalability, you should implement your
>> explicit transaction inside of a stored procedure, not from client
>> code. The basic idea is you collect *all* input from the user first,
>> then call your wrapper stored procedure, passing it all of the user
>> input as input parameters. That stored procedure then initiates an
>> explicit transaction with a BEGIN TRAN statement, calling the other
>> stored procedures as required, passing each one the information it
>> needs. <snip>
>
>Thanks for the response Mary. I have used this technique when I could and
>have transactionos in some stored procedures. However, I do not see how to
>use this technique in the current situation. I probably was not clear.
>
>In this case, I have a base table with several repeating groups, seven
>actually. For the repeating groups, I can have as many rows as the user
>inputs for any or none of the tables. So, without some more research, I do
>not know how to get all of that user input to SQL Server from a single stored
>procedure. Does SQL Server 2000 have some capabilities that I should
>research? Or maybe you are talking about writing XML from the app and
>sending that single document to SQL Server. More info please?
>
>Fortunately, this particular situation was for two reference tables that do
>not change very often.
>
>With the day-to-day data capture, which is not coded just now, I hope to
>figure out enough to use datasets with multiple tables and their
>relationships. After the user builds a dataset, then the stored procedure
>commands will do the update with something like dataset.update, or whatever.
>But this also sounds like multiple trips from the application to SQL Server
>for one commit.
>
>Thoughts?
>
>Thanks, Alex
.
- Prev by Date: Re: How to reteive data amongst different datatable within a datas
- Next by Date: DataTable/DataSet question
- Previous by thread: NEED HELP! : Internal Connection Fatal Error
- Next by thread: DataTable/DataSet question
- Index(es):
Relevant Pages
|