Viewing 15 posts - 57,706 through 57,720 (of 59,101 total)
Outstanding... thank you for the feedback.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2006 at 6:52 am
Ok... first things first...
Rob... I'm confused... I thought you were saying that some sproc OUTSIDE of the trigger was being rolled back and that you need what was happening inside...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 11, 2006 at 8:56 pm
The only way to keep from rolling back the record inserted by the trigger, is to do it with another connection.
SP_OA could be used to create such a connection...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 11, 2006 at 6:54 pm
...and, still, if you have FULL RECOVERY set, none of that will help the LOG file because all of the updates will be recorded whether they be single updates, batches,...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 11, 2006 at 5:54 pm
JUST in case you need it as a single query (In the absence of CTE's, I do like the temp table solution better which is why I didn't answer previously...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 11, 2006 at 5:50 pm
Yes, it does make sense... What I'd recommend is writing a script that would populate a working table (permanent table that will last until this problem is resolved and then...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 11, 2006 at 8:13 am
The update isn't really ignored if there's no match... it just doesn't update anything although it is executed.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 11, 2006 at 6:51 am
Try adding the -c parameter. If that doesn't do it for you, add the -C parameter with the proper code page (see Books Online for the proper code page.) Do...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 11, 2006 at 6:50 am
Yes... you can insert the output of a SELECT into a temp table with an IDENTITY column to keep track of which rownumber you are working on. Then, loop through the...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 11, 2006 at 6:47 am
I think you have it... the only thing that I would change is UNION to UNION ALL since it's not likely that there will be any overlap between the two...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 11, 2006 at 6:43 am
Johann,
Since you're new, the error at lines 24 and 42 was because you cannot have a WHERE clause in an INSERT/VALUE statement. Sreejith corrected that by changing it to an INSERT/SELECT.
The...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 10, 2006 at 10:52 am
Take a look at Books Online for the OSQL command... the problem is that the default output is set to 80 characters and you must invoke the "-w" parameter with...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 10, 2006 at 10:19 am
I gotta ask the question, again... you do realize that, except for the Developer's Edition, SQL Server must be installed on a Windows Server...? You've not said that you are actually...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 10, 2006 at 9:25 am
You are not wrong. Conversely, if you don't want the IDENTITY column to be reset to the SEED value, you must use DELETE, instead.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 10, 2006 at 9:18 am
In that case, why not just update by what's in the MediaID column? Load the unique media IDs into a temp table (with an autonumbering IDENTITY column) and step through...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 9, 2006 at 1:44 pm
Viewing 15 posts - 57,706 through 57,720 (of 59,101 total)