Viewing 15 posts - 38,296 through 38,310 (of 59,072 total)
{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
lmu92 (5/18/2010)
SELECT * FROM
(
SELECT 'Smith John' AS lastname UNION ALL
SELECT 'S#ith Jane' UNION ALL
SELECT '\ Jim' UNION ALL
SELECT 'Anderson Ken' UNION ALL
SELECT 'Smith-Barny Andre'''
) a
WHERE...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 18, 2010 at 4:45 pm
Heh... great minds think alike, Lutz... your post wasn't there when I started typing my post. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
May 18, 2010 at 4:35 pm
Hmmmm... I'm thinking you could get a false count if the data looked like...
Re-Open
whatever
whatever
Re-Open
whatever
whatever
Ready For Build
I don't know if that could ever happen but I see nothing to prevent such...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 18, 2010 at 4:35 pm
MTY-1082557 (5/18/2010)
My end user is not our developers, are the users that manage the application. I'm thinking about the Express Edition. I never heard about the compact...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 18, 2010 at 4:21 pm
I actually did mean "Nice Try" as in "good job" and "almost right". It was meant to be a compliment because I've seen many posts that don't...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 18, 2010 at 4:14 pm
Rob Schripsema (5/18/2010)
I do not think ISDATE() is a good way to solve the problem OP has. Also, given the anomalies, I was wondering when would you use ISDATE() and...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 18, 2010 at 3:58 pm
rjv_rnjn (5/18/2010)
Rob Schripsema (5/18/2010)
--Jeff Moden
Change is inevitable... Change for the better is not.
May 18, 2010 at 3:15 pm
sql.kishore1 (5/18/2010)
Rob Schripsemasolution Solves my ISSUE.
Rob's code is technically correct for what it was intended to do but you need to make real sure that you don't have entries...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 18, 2010 at 3:10 pm
Dobermann (5/18/2010)
On the Dose/Frequency thing... it shouldn't make a difference. If the code works on one it should work...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 18, 2010 at 3:06 pm
Heh... maybe it is I who is going brain dead concerning changes in requirements but ...
Dobermann (5/17/2010)
--Jeff Moden
Change is inevitable... Change for the better is not.
May 18, 2010 at 7:39 am
Very cool. Thanks for the time to make a feedback. If you get the chance, post your code so folks can see what you've done with PIVOT.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 18, 2010 at 7:23 am
Viewing 15 posts - 38,296 through 38,310 (of 59,072 total)