Viewing 15 posts - 38,056 through 38,070 (of 59,072 total)
david meagor (6/7/2010)
If that becomes an issue then I can filter later.
Heh... better get your filters ready because it will become an issue. It always does.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2010 at 5:50 am
Venkatesan Prabu (6/6/2010)
create table sample_table (id int, dat datetime)
insert into sample_table values(1,getdate())
select * from sample_table
select id,dat from sample_table where datename(month,dat)='June'
-----------------------------------------
id ...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2010 at 9:28 pm
WayneS (4/15/2010)
lmu92 (4/15/2010)
blah blah blah.... Right, Wayne?uh, sure, jeff :w00t:
Heh... now what the hell do you mean by that? 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2010 at 9:05 pm
Looks good, Lutz. I just wish there were a way to keep from having to read the same table 4 times although I believe it'll still smoke a cursor...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2010 at 5:43 pm
lmu92 (6/6/2010)
When talking about the double row_number approach I was referring to the sample code I provided a few posts back (not the "deep dive" approach though).
It's showing...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2010 at 4:38 pm
It is possible that someone disabled the unique constraint, added data, and then reenabled the constraint with WITH NOCHECK activated (IIRC).
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2010 at 4:32 pm
Before we go about trying to solve this problem... have you considered how many foul words you will spell out with such random codes?
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2010 at 4:25 pm
Remember that the most successful managers are well informed and loyal leaders that set the example and are more like coaches than managers. Remember, also, that if you want...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2010 at 4:20 pm
Heh... when a patient comes in with a bone sticking out of the skin, guess what's wrong. 😉
I agree... too many people treat symptoms on SQL Server and, many times,...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2010 at 4:07 pm
Robert Goode (6/2/2010)
Many thanks for posting this. If I could ask how I would go about modifying it to return the correct date and time based on an input...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2010 at 3:35 pm
timmynew11 (6/4/2010)
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2010 at 3:20 pm
lmu92 (6/6/2010)
Jeff, are you saying a c.u.r.s.o.r. should be preferred instead of the "double-row-number" approach??
In this case, yes because of the way the double row number problem needs to be...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2010 at 1:52 pm
timmynew11 (6/6/2010)
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2010 at 1:41 pm
sgtwilko (6/5/2010)
We always try to keep the datetime as a...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2010 at 11:15 am
cgreathouse (6/5/2010)
The limitation with this approach is you can't have more than 32,767 rows. But for my case this isn't an issue.
Heh... why do people insist on building "time...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2010 at 10:29 am
Viewing 15 posts - 38,056 through 38,070 (of 59,072 total)