Viewing 15 posts - 55,021 through 55,035 (of 59,098 total)
p.s. Don't ever change the TempDB recovery mode... it's not necessary and will drop some performance.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 18, 2007 at 7:43 am
Master, MSDB, and TempDB are defaulted to "Simple" recovery. Master can be changed to Full Recovery and then I think you can do a transaction log backup. Not 100% sure, though.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 18, 2007 at 7:42 am
Thanks, Mark... it takes DOS-like wildcards (*) as well...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 18, 2007 at 7:36 am
Have BCP do a Queryout from a sproc or a view that does a union between some column names and data... keep in mind that all of the data must...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 17, 2007 at 9:32 pm
Perhaps it's just a language barrier problem... but, if it's not, I agree with Serqiy... why would you need to count the number of columns present in a table? --Jeff Moden Change is inevitable... Change for the better is not.
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
September 17, 2007 at 6:45 pm
In our case, the term "clone" would be more appropriate. Not sure how it works, but it just takes a couple of minutes everynight on a tera-byte database. Has something...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 17, 2007 at 6:34 pm
How does that produce the dynamic sizing the OP asked for? That code works great on the input but does nothing for formatting the output in the text window.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 17, 2007 at 5:43 pm
Michaeal said it right...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 17, 2007 at 5:43 pm
| There's too many tables being updated, so a trigger is out. |
Write a sproc to generate the trigger code...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 17, 2007 at 5:35 pm
It would be good if you posted one of the offending lines of code (sans password)... there's lot's of options in BCP...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 17, 2007 at 5:30 pm
Good golly, folks... open Query Analyzer and press {f4}....
--Jeff Moden
Change is inevitable... Change for the better is not.
September 17, 2007 at 5:27 pm
This probably doesn't help, but the right way to do it would be to deny all users the ability to create procs and to follow a code promotion process.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 17, 2007 at 5:23 pm
Thanks for taking the time for the explanation, Rog...
But... being able to pass tables to stored procedures, with the understanding that you will have multiple tables with the same...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 17, 2007 at 7:19 am
Let us know what you finally come up with so that others may learn, as well.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 16, 2007 at 7:55 am
Heh... did you try it?
--Jeff Moden
Change is inevitable... Change for the better is not.
September 16, 2007 at 7:54 am
Viewing 15 posts - 55,021 through 55,035 (of 59,098 total)