Viewing 15 posts - 57,676 through 57,690 (of 59,067 total)
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
Would you post your "adaptation" please?
--Jeff Moden
Change is inevitable... Change for the better is not.
September 9, 2006 at 10:24 am
I suppose there's a way... but, instead, I normally create a temp table with the results of the called proc and then just join to the temp table.
Create the temp...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 9, 2006 at 10:18 am
What's not working? The only thing I see at a quick glance is that you are trying to insert @@OutID instead of @OutID in the details table.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 9, 2006 at 10:12 am
I ran your original examples on my production box... both execution plans are identical and they both have parallelism.
Could it be that someone screwed up and turned of auto-calc...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 8, 2006 at 5:24 pm
Viewing 15 posts - 57,676 through 57,690 (of 59,067 total)