That situation is exactly what transactional databases are designed to do,
so it'll be nice and fast.  Unless those updates are changing a heck of a
lot of data or you're running on a massively underpowered machine, the
transaction won't make SQL Server blink.  You can always optimize (index
fields used in WHERE clauses, remove indexes from other fields, etc), but
the core operation will be plenty fast.

> -----Original Message-----
> From: Eric Creese [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 26, 2004 8:49 AM
> To: CF-Talk
> Subject: OT - Datbase Transaction question
>
> I have a stored procedure which runs a series of updates,
> actually 28 seperate update statements. If no failures I then
> do a single commit. if error roll back all updates. Kind of
> an all or nothig deal. Where will the biggest performance hit
> take place?
>
> SQLServer 2000
>
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]

Reply via email to