Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.databases.ms-sqlserver    |    Notorious Rube Goldberg contraption    |    19,505 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 18,233 of 19,505    |
|    Erland Sommarskog to Gene Wirchenko    |
|    Re: SSE 2008: Table Trigger    |
|    13 Apr 11 00:09:39    |
      XPost: microsoft.public.sqlserver.programming       From: esquel@sommarskog.se              Gene Wirchenko (genew@ocis.net) writes:       > I prefer to have the one trigger instead of two nearly-identical       > triggers. That is why I have @AccessType. Good or bad? Is there a       > better way of determining between insert and update?              You are on the right track, but this is better:               IF exists (SELECT * FROM deleted)              No need to actually count the rows!              > What sort of error handling should I have? While this code does       > work for multiple rows, I need a handling for if one or more       > inserts/updates fail, and it should be something that returns       > reasonable detail to the application.              By default when you are in a trigger, the first error will abort the batch       and rollback the transaction.              > declare #Inserted insensitive cursor              Good boy!              This is actually better in a way:               DECLARE cur CURSOR STATIC LOCAL              STATIC and INSENSITIVE have - as far as I know - the same meaning, the       rows are copied to a work table in tempdb. This gives a predictable and       understandable behaviour. The default cursor is a dynamic cursor, and       it's good that avoided this trap.              The reason that STATIC is better is that this proprietary keyword       (INSENSITIVE is ANSI) permits you to specify LOCAL which means that       the cursor disappears when then scope exits, no matter how it exits.       The default is global which means that the cursor still exists. Which       can cause nasty surprises next time.              In fact, I would expect this to happen to you, because you only have       CLOSE at the end. You need DEALLOCATE instead. With CLOSE the cursor       still exists.              # in the beginning of the cursor name is a little odd.              > open #Inserted       >       > fetch next from #Inserted into @ACUK,@ACOrd,@ACName,@ACNr       >       > while @@fetch_status=0                     I prefer to write this as                      WHILE 1 = 1        BEGIN        FETCH cur ...        IF @@fetch_status <> 0        BREAK              Then you only need FETCH statement, and one less line to change if you add       one more column to the cursor.                            --       Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se              Links for SQL Server Books Online:       SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx       SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca