The forum will experience an outage sometime between February 10 at 7:00pm EST and February 12 at 11:59 EST for installation of security updates. The actual time and duration of the outage are unknown but attempts will be made to minimize the downtime. We apologize for any inconvenience.

Hi, My cursor stops after hitting a rollback. How can i continue processing after a rollback occurs?

Thanks, Greg

Here is my code:

DECLARE @supplied_date DATE SELECT @supplied_date = '2014-12-10' //Change the supplied date

DECLARE service_fut_curs CURSOR FOR SELECT service_code FROM service_future WHERE effective_date > @supplied_date

DECLARE @future_code        varchar(20)
DECLARE @existing_code      varchar(20)
DECLARE @rowcount           INT

OPEN service_fut_curs WITH HOLD         
FETCH service_fut_curs INTO @future_code

WHILE (@@sqlstatus = 0) 
    SELECT service_code 
      INTO @existing_code
      FROM Service
     WHERE service_code = @future_code and active = 'Y'

    /* Move existing service to the service_hist table */
     INSERT INTO service_hist 
        (service_code, description, service_class, service_type, wt_low, wt_high, piece_cost, wt_cost, 
         vendor_id, ww_zone, last_ws, last_user, last_date, last_time, "comment", active, effective_date, country_code,
         level_id, bill_zone1, bill_zone2, bill_zone3, bill_zone4, bill_zone5, mail_class_id, pri_min_wt, pri_max_wt, actual_country_code, active_date,
         inactive_date, product_code, currency_code, volume_piece_min, volume_piece_max, matrix_id, piece, piece_wt, wt,
         hts_code, value_range_from, value_range_to) 
     SELECT service_code,description,service_class,service_type,wt_low,wt_high,piece_cost,wt_cost,
       FROM service 
      WHERE service_code = @existing_code

    IF @@ROWCOUNT = 0
        Select  'Warning: No rows were inserted into service_hist '

    IF @@ROWCOUNT = 1
        Select  'Success: 1 row was inserted into service_hist '

        -- Delete existing service from the service table
        DELETE FROM service WHERE service_code = @existing_code
        IF @@ROWCOUNT = 0
            Select  'Warning: No rows were deleted FROM service'

        IF @@ROWCOUNT = 1
            SELECT 'Success: 1 row was deleted FROM service'
            --Insert New service into the service table
            INSERT INTO service (service_code,description,service_class,service_type,wt_low,wt_high,piece_cost,wt_cost,
            SELECT service_code,description,service_class,service_type,wt_low,wt_high,piece_cost,wt_cost,
              FROM service_future 
             WHERE service_code = @existing_code

            IF @@ROWCOUNT = 0
                Select  'Warning: No rows were inserted into the service table'

            IF @@ROWCOUNT = 1
                Select  'Success: 1 row was inserted into the service table'
                      DELETE FROM service_future WHERE service_code = @existing_code 
                IF @@ROWCOUNT = 0
                    Select  'Warning: No rows were deleted From service_future table'

                IF @@ROWCOUNT = 1
                    SELECT 'Success: 1 row was deleted From service_future table'
            END -- check insert into service table
        END -- Check deleted FROM service'
    END -- check inserted into service_hist

    SELECT @rowcount =  @rowcount + 1
    FETCH NEXT service_fut_curs INTO @future_code        
END -- loop

CLOSE service_fut_curs         
DEALLOCATE service_fut_curs

asked 12 Jan '15, 10:28

GregC's gravatar image

accept rate: 0%

edited 12 Jan '15, 10:52

By default, cursors are closed at the end of transaction (commit or rollback). When you open a statement, you can specify that it be opened "WITH HOLD" to indicate it should remain open after the transaction.

Be aware that the semantics of a cursor being held open past a transaction, particularly after a rollback, are unusual and require special attention. The option ansi_close_cursors_on_rollback can be set to force even WITH HOLD cursors to close on ROLLBACK (this is the behaviour defined by the ANSI SQL Standard for WITH HOLD cursors). Some of these semantic issues can be sidestepped if you use an INSENSITIVE cursor type that would take a copy of the data at open time and not be sensitive to changes in the values of the referenced tables.

This is not in your question, but I occasionally am surprised when converting a FOR loop into an explicit cursor and forget to include WITH HOLD. The FOR loop implicitly opens the cursor with WITH HOLD and it will not close automatically after a commit. The cursor may be closed after a ROLLBACK depending on the ansi_close_cursors_on_rollback option.

permanent link

answered 12 Jan '15, 11:33

Ivan%20T.%20Bowman's gravatar image

Ivan T. Bowman
accept rate: 39%

Thanks Ivan,

I was wondering if the there is another approach to handle this process. For each row that meets the cursor criteria, I need to:

  1. Find the existing record in the service table
  2. Move it to a history table
  3. Delete existing row from the service table
  4. Insert row into service table from the future table
  5. Delete row from the future table



(12 Jan '15, 12:39) GregC
Replies hidden

This may be a good use case for DML-derived tables [1]. You could use one statement to delete rows from one table (service) and insert into the target (history). I haven't personally used the feature so I haven't crafted an example. I am not sure whether DML-derived tables can be used with the TSQL dialect (it appears your example uses TSQL dialect).


(12 Jan '15, 20:14) Ivan T. Bowman

As we are using SQL, would it not be easier to use set statements, i.e. instead of using a cursor "one row at a time" approach, do all the "move" operations for all according row in one go?

One approach to do so would be to define a temporary table to identify all according rows (e.g. all "service_code" values) and then use joins to insert/delete all according rows from the according tables. (The temporary table would only be required if the matching rows may not be identified lateron, i.e. when the "moves" themselves would prevent the rows to be filtered again.)

Apparently, that would usually mean to use one transaction for all rows whereas a row-by-row approach might allow several rows to be moved whereas other row moves may be rolled back.

This is just a very general hint, without knowing the table schema (and particulary the FK relationship between tables "service", "service_future" and "service_hist" it's difficult to tell whether this will work for you...

Another approach would be to include all rows in the same table and use a status field to tell whether these are "historical" or "current" or "future" entries - "moving" would then be simplified to modify the status field.

(13 Jan '15, 03:52) Volker Barth
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 12 Jan '15, 10:28

question was seen: 495 times

last updated: 13 Jan '15, 03:56