Viewing 15 posts - 57,646 through 57,660 (of 59,067 total)
SwTrans,
I guess I don't see what your problem is or what you're actually trying to do... why wouldn't the following work for you?
DECLARE @UseIt1 as varchar(100)
DECLARE @WorkQueue AS VARCHAR(100)
SET @WorkQueue...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 9:14 pm
Sushila,
You're having one of those days like I did on the trigger thing... ![]()
DECLARE @UseIt1 as varchar(100)
EXEC ('SET ' + @UseIt1 +...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 9:03 pm
Whew! The number 6 would have really messed me up... I only have 5 fingers on each hand! ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 8:54 pm
Yep... and keep in mind that SELECT/INTO only works once on any given target table unless you drop the table... but that would defeat the archive, eh ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 8:51 pm
Lee,
You used the key words "query the dataset". Cursors contain a bunch of rows but they can only be worked on or "fetched" one agonizing row at a time. If...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 8:48 pm
Sure you do... "Old" = Parent, "New" = Child. It's a classic hierarchical problem. There has to be a dozen good articles and lot's of good posts on this forum...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 8:34 pm
I believe that what you are looking for may be solved with "dynamic SQL". There has to be a thousand good postings on this forum about it... try a search...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 8:28 pm
I've found the even Microsoft uses the "undocumented" features
Works for me!
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 8:24 pm
Concure with that... isn't there an autonumbering column or a date/time column or a consecutive ID column of any sort? How about a clustered primary key? There has to be something...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 8:22 pm
I've never seen it fail either (and it's been 10 years)... however, the first article says it's guaranteed to be OK if you create the table with the IDENTITY column...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 8:16 pm
Thought I'd throw my 2 cents in here because lot of folks run into some real problems when using ranges of dates as criteria...
BETWEEN is fine for date ranges......
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 8:07 pm
Sorry... was in a hurry and forgot that you were using a
cursor
and I...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 7:38 pm
Yah... forgot that the NTEXT data type is being used... sorry.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 7:24 pm
Of course it's only creating one file... that's because you hardcoded the output file name as c:\Person_notes.txt.
You need to make the file name dynamic, as well. Perhaps using the...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2006 at 8:11 am
John,
Understood... I just don't make those same assumptions... if the requester knew about those types of things, they might not have needed to ask the original question ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
September 13, 2006 at 7:19 pm
Viewing 15 posts - 57,646 through 57,660 (of 59,067 total)