Viewing 15 posts - 42,736 through 42,750 (of 59,067 total)
Thanks for the feedback. I learned some stuff myself. Good thread! 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2009 at 4:37 pm
Lynn Pettis (7/24/2009)
.,.,., why not let Jeff post the url? Others, like myself, may just benefit ... oh, you want to keep us in the dark, like mushrooms! 😛
Agh......
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2009 at 4:31 pm
Ever try to hit a thrown pork chop in mid air? 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2009 at 2:12 pm
ozkary (7/24/2009)
yes, fine tuning the queries to get the best performance is always welcome.
For production environment, I suggest to process/publish the conversion of IP to num during the...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2009 at 2:07 pm
@ Mark...
Heh... that's what I get for looking at stuff before the caffeine reaches the brain. Thanks, Mark... nicely done.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2009 at 10:05 am
Mark (7/13/2009)
create function dbo.ConvertIp2Num(@ip nvarchar(15))
returns bigint
as
begin
return ((cast(parsename(@ip,4) as bigint)*256+
cast(parsename(@ip,3) as bigint))*256+
...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2009 at 9:01 am
tdcheek (7/10/2009)
IP's fit much better in binary(4) than bigint - the conversion is pretty simple and cuts down heavily on reads and index size
What is your method of conversion? ...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2009 at 8:57 am
happycat59 (7/23/2009)
Using COUNT(1) requires SQL Server to return all records that meet the criteria.
Ummmm.... nope... it doesn't... it stops searching as soon as it finds one record that meets the...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2009 at 8:31 am
. (7/24/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2009 at 8:26 am
ChandraMohan Nandula (7/23/2009)
Hi Jeff,Thanks a lot for providing the solution. I will check it and revert back to you.
Thanks, Chandra. I appreciate the feedback.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2009 at 8:22 am
Yeah... unfortunately, triggers are the only way to do any type of DRI between databases. Make sure that they're not RBAR and that they're well written (ie: performant) and...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2009 at 8:20 am
If you just want to guarantee exclusive use for a heavy operation, you don't need to do that. Just use the WITH(TABLOCKX) hint and when it's able, it'll lock...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2009 at 8:16 am
. (7/24/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2009 at 8:14 am
Thanks for the feedback, Ghanta...
There's gotta be a way to do this (auto recognition and intermitent use of text qualifiers) without having to fire up SSIS or writing a CLR...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2009 at 6:51 am
Almost forgot... it would be a help if you attached the CREATE TABLE statment for your table as a text file. Thanks.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2009 at 6:47 am
Viewing 15 posts - 42,736 through 42,750 (of 59,067 total)