Viewing 15 posts - 40,636 through 40,650 (of 59,071 total)
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
sturner (12/14/2009)
email on the way
It would be really cool if you'd attach it to this post. Thanks.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 14, 2009 at 10:37 pm
Nabha (12/14/2009)
http://www.sqlservercentral.com/articles/Best+Practices/61537/
Is this what you need?
select geog.region_name, sum(sales) AS Total_sales
from store_info inner join geog
On geog.store_name = store_info.store_name
Where geog.region_name = 'west'
group by...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 14, 2009 at 10:34 pm
This isn't a subject to be taken lightly... inventory management is complex and frequently changing. It's not something that can be learned correctly in a couple of hours especially...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 14, 2009 at 10:30 pm
Paul-755326 (12/14/2009)
Improvements and efficiency gains will come later.
Heh... no they won't... no one will give anyone the time until they actually become a problem, at which point, it will be...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 14, 2009 at 10:27 pm
mrdenny (12/14/2009)
Using xp_cmdshell pretty much isn't ever a good idea, as for security reasons xp_cmdshell should be disabled.
Properly setup proxies take care of such concerns... especially on non-public facing ETL...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 14, 2009 at 10:17 pm
You bet. Thank you for the feedback and thank you for taking the time to setup the code to make giving you an answer so very easy.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 14, 2009 at 9:58 pm
krypto69 (12/14/2009)
My users need the ability to go back in time and search on data say from the end of last...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 14, 2009 at 9:55 pm
Gail... just checking because I'm low on coffee... does that work only if the table isn't a heap?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 14, 2009 at 9:53 pm
clive-421796 (12/14/2009)
@liTimeOffset INT
SET @liTimeOffset = 120
SELECT DateAdd(n, @liTimeOffset, LocationDateTime)
FROM mytable
WHERE
LocationDateTime >= (CONVERT(VARCHAR(10), @StartDate, 120) + RIGHT(CONVERT(VARCHAR, @StartHour, 100),7))
AND
LocationDateTime < (CONVERT(VARCHAR(10), @EndDate, 120)...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 14, 2009 at 9:50 pm
jinx8402 (12/14/2009)
I know and understand performance will...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 14, 2009 at 9:43 pm
Stamey (12/14/2009)
Learning something new on every visit to SSC. Hoping to pass it on to someone else.
Man... I love that tagline. "Pass it forward".
Unfortunately, I don't know an...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 14, 2009 at 9:41 pm
John Rowan (12/14/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
December 14, 2009 at 9:38 pm
Viewing 15 posts - 40,636 through 40,650 (of 59,071 total)