Viewing 15 posts - 38,311 through 38,325 (of 59,098 total)
Heh... thanks niteshrajgopal...
It might be more appropriate to say that I know "other people's stuff". I didn't invent any of these methods... I just get lucky putting them together....
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2010 at 8:16 am
Oooooohhh.... I think I get it now. Remember when I said we need to define what a change in frequency is? We still need to do that (at...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2010 at 8:06 am
Dobermann (5/18/2010)
Well, this one is closer, but sorry to say still not 100% correct.
When I ran this:
SELECT K9ID, MedID, Dose, Frequency
FROM #RX
ORDER BY K9ID, MedID, RxStartDate
against #RX,...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2010 at 7:49 am
That's a pretty interesting way to calculate "Median". Haven't tried it but it looks fast. I know a different way that we can test together tommorow night. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2010 at 1:00 am
Hmmmm... for some reason, the reply didn't "bump" on "Posts Added Today". I hope the OP got notified.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2010 at 12:46 am
ColdCoffee (5/18/2010)
THE MAN of SSC
Heh... thanks for the compliment but there's good people on this forum that can improve on that code. Everytime I get lucky and pull something...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2010 at 12:38 am
ColdCoffee (5/18/2010)
Jeff Moden (5/18/2010)
niteshrajgopal (5/18/2010)
Hi again, is there anyway I can add to your reputation or something on this forum:-)
Heh... not to worry. CC is building his reputation where...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2010 at 12:33 am
Heh... ok... time to get down to some T-SQL. 😛
The following code builds some test data. Actually, it builds a lot of data just to be sure we have...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 18, 2010 at 11:49 pm
Jo Pattyn (5/17/2010)
It was the connection option numeric round_abort (Database Properties > Options > Numeric Round-Abort)
That was the weirdest error I've seen in quite a while... thanks for posting what...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 18, 2010 at 9:56 pm
Heh... no response... guess that fell on deaf ears.
Just in case someone is still listening and for the record, the code that Matt Miller posted will blow the doors off...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 18, 2010 at 9:53 pm
Sorry for the delay... here's an "Inline Table Valued Function" (iTVF) with a bit of flexibility built in. It's not a panacea but it certainly works for this particular...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 18, 2010 at 9:24 pm
{edit} Sorry... had a bug in the code and had to remove this post.
{edit} {edit} Heh... it turned out to not be a bug. The Tally table code...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 18, 2010 at 8:48 pm
Here you go... I guarantee that it only finds changes, now...
--===== If the test table already exists, drop it
IF OBJECT_ID('TempDB..#RX','U') IS NOT NULL
...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 18, 2010 at 7:13 pm
Ah... I see why you say too many rows showed up. We need to define what actually needs to happen when the Frequency changes. The current definition is...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 18, 2010 at 6:50 pm
Just curious... how many rows do the tables actually have in them? The fact that DISTINCT is being used to overcome some obviously duplicated output leads me to believe...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 18, 2010 at 4:53 pm
Viewing 15 posts - 38,311 through 38,325 (of 59,098 total)