Viewing 15 posts - 53,056 through 53,070 (of 59,098 total)
This will do it...
declare @temp table (t int)
insert into @temp
select 234000 --.65
union all
select 2052000 -- 5.7
union all
select 1638000 -- 4.55
union all
select 1620000 -- 4.5
select *, t/36000.0 ,t/36000
from @temp
WHERE t/36000<>t/36000.0
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2008 at 6:15 pm
Adrienne (1/8/2008)
declare @temp as table (t int)
insert into @temp
select 234000 --.65
union all
select 2052000 -- 5.7
union all
select 1638000 -- 4.55
union all
select 1620000 --...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2008 at 6:09 pm
July (1/8/2008)
EXEC xp_dirtree "\\machine\shrarename" but I obtain "system cannot...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2008 at 6:02 pm
SELECT Part, MAX(Date) AS Date
FROM yourtable
GROUP BY Part
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2008 at 5:56 pm
...and it would be a lot faster if you used BULK INSERT or BCP...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2008 at 5:49 pm
That's not such a bad idea (ad hoc usage to solve a very specific problem)... what is a bad idea is using non-temptable names for everything that you would normally...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2008 at 5:22 pm
Heh... small world we live in, huh?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2008 at 5:13 pm
Thanks for the great feedback, Ian... especially about keeping it casual (ie. fun) and the remarks about documentation... We've actually put sime "documentation standards" into play at work. They're...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2008 at 5:03 pm
Heh... I was thinking the same thing... beating are fun especially when delivered by code...
Since it's 2k5, I wonder if you could add a schema trigger to TempDB to sweep...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2008 at 4:54 pm
Speaking of testing... if you value your production system, now would be a good time to setup a testing twin so you can do full regression testing of the SP...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2008 at 4:39 pm
Just my experience... I keep a Tally table of 11k rows... sure, it covers the usual split of a VARCHAR(8000) but I use it for much more... if you consider...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2008 at 4:32 pm
Have you taken the time to verify that you actually have the problem?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2008 at 7:39 am
Dunno about that... but I do know that throwing indexes at tables will absolutely not help code that is written incorrectly because the code will not be able to use...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2008 at 7:37 am
Perfect... thanks for the feedback.
Yeah, anytime you have a join on different datatypes, it must do an implicit conversion to do the join... best you can get out...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2008 at 7:35 am
You see the need to split a parameter with more than a million characters?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2008 at 7:31 am
Viewing 15 posts - 53,056 through 53,070 (of 59,098 total)