Viewing 15 posts - 40,651 through 40,665 (of 59,098 total)
I wondered about this... with the advent of CROSS APPLY and a well written While Loop like what Alexey Eliseev wrote on this thread, a While Loop solution looks like...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2009 at 8:45 pm
schedde (12/15/2009)
Create Table #Id (n int)declare @d datetime
set @d = getdate()
declare @s-2 varchar(max)
set @s-2 = '3903044,7569634,3947703,4397641,8304414,3889301,504543,5543592,2468890,644965,3343....
EXEC Util_ReadIdList @IdList=@s
select datediff(millisecond, @d, getdate())
Thanks, schedde. Do...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2009 at 8:40 pm
Roland Howard Boorman (12/14/2009)
Using XML whole complex structures can be passed to SQL and treated as Tables.
You can use Functions with the XML to render these...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2009 at 7:09 pm
schedde (12/15/2009)
Simple testing took 0.4 seconds to load 10,000 numbers.
What did the simple testing look like? In other words, was that all in a single "variable" or was that...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2009 at 6:20 pm
homebrew01 (12/15/2009)
GilaMonster (12/15/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2009 at 4:52 pm
Thanks for the feedback, Calvin. Like you say, it's always good when someone comes to the same conclusion. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2009 at 4:28 pm
krypto69 (12/15/2009)
Jeff Moden (12/14/2009)
krypto69 (12/14/2009)
My users need the ability to go back in time and search on data say from the...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2009 at 10:52 am
I know this is an old article but I'm glad I found it. I agree 100% for homegrown stuff. Sure, if you have to follow a given naming...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2009 at 9:09 am
Yeah... that should do it. I just hate using it because it will, in fact, do it for all the DB's and that's not usually what you want.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2009 at 6:33 am
Bhavesh_Patel (12/15/2009)
No, there is no column that defines the order of the cities ...
Then, make a sister table (either permanent or temporary) and use it.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2009 at 6:27 am
Are you using the "-R" argument of SqlCmd?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2009 at 6:24 am
GilaMonster (12/15/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2009 at 6:15 am
If all the "fields" in this monster table are all in good order, then this shouldn't be a problem at all. I haven't had to look it up in...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2009 at 6:12 am
schedde (12/14/2009)
Here is solution using OPENXML:
Have you ever tested that for performance or resource usage?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 14, 2009 at 10:52 pm
Ummmm.... do you mean that you're going to do a join on a >900 character VARCHAR or that someone using a GUI is going to type more than 900 characters...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 14, 2009 at 10:40 pm
Viewing 15 posts - 40,651 through 40,665 (of 59,098 total)