Viewing 15 posts - 55,906 through 55,920 (of 59,098 total)
Thanks, Steve,
The thing that really kills me is the cruddy data that poor ol' Jerry (the OP) has received. The data can be imported and correctly parsed even making some...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 6, 2007 at 8:21 am
Great idea... thanks everyone...
Carl, thanks for the original idea that everyone seems to be hitting on.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 6, 2007 at 8:15 am
Rog,
I appreciate the compliment. A long time ago, I realized that the first step towards the "Sql excellence" you speak of is correct identification of the given problem...
Apparently, though,...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 6, 2007 at 8:11 am
You mean just use a scheduled job? Or is there some way to allow the user to start the job "indirectly"?
--Jeff Moden
Change is inevitable... Change for the better is not.
July 6, 2007 at 7:47 am
The one David was talking about is actually available in "Help" in Query Analyzer... it's also known as "Books OnLine".
--Jeff Moden
Change is inevitable... Change for the better is not.
July 6, 2007 at 12:15 am
Heh... did for me... data is pretty well broke... ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
July 6, 2007 at 12:13 am
Thanks for the info guys... like I said, I may have to reevaluate my position on where to store images. ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
July 6, 2007 at 12:08 am
Not sure why you have the first EndDate becoming a start date but whatever... the following will do what you ask for...
SELECT Client_NHI, MIN(End_Date) AS StartDate, MAX(End_Date) AS EndDate FROM...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 5, 2007 at 8:06 pm
Nope... I'm pretty well spammed out on RAC. How about posting the T-SQL solution that it's supposed to replace?
--Jeff Moden
Change is inevitable... Change for the better is not.
July 5, 2007 at 7:59 pm
Would have been a bit helpful to know that up front.
First, whatever you do... do NOT use dynamic SQL for this because you are allowing the user to type whatever...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 5, 2007 at 7:56 pm
Heh... if you run into a "toughy", c'mon back... lot's of good folks waiting in the wings... ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
July 5, 2007 at 6:23 pm
And, don't use recursion to solve this... SQL Server 2000 cannot go "N" levels... it's limited to only 32 levels and then "BOOOOOOM!"
--Jeff Moden
Change is inevitable... Change for the better is not.
July 5, 2007 at 6:22 pm
Based on the original code you posted, you shouldn't have a problem...
The @bfr_tag holds 634 characters.
@general_notes holds a max of 2500 characters.
@day_notes holds a max of 2500 characters.
@nite_notes holds a...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 5, 2007 at 6:20 pm
Thank you for the feedback...
If you are still having problems or need to use "row_number" (now that we know you are using 2k5) instead of an Identity column, please post...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 5, 2007 at 8:31 am
Actually, they did... nice red/white/and blue google with a bald eagle and the whole shootin' match. I believe Google logins sense which country you are in to allow for if...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 5, 2007 at 8:06 am
Viewing 15 posts - 55,906 through 55,920 (of 59,098 total)