Viewing 15 posts - 44,686 through 44,700 (of 59,101 total)
Yeah... I agree... the written requirements weren't that clear. The desired return posted along with the attempted code and the existing data was the key.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2009 at 1:59 pm
Richard Hurst (3/10/2009)
I just did because the whole thing was driving...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2009 at 1:56 pm
Spikemarks (3/10/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2009 at 1:53 pm
robert.mason (3/10/2009)
Jeff Moden (3/6/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2009 at 1:03 pm
You bet, Todd... Thanks for the feedback. Heh... It's amazing how long the myth of Select/Into has managed to survive.
I'll have to look for it, but I've got a...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2009 at 12:58 pm
Thanks for the kudo, Ross :blush:
I also understand that there are times when the Consultant or other 3rd party wants to protect proprietary code through encryption... that, too, should be...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2009 at 6:27 am
The problem with your tests is that the time to display the results are being included. Also, as you saw in your own testing, converting the date to CHAR(8)...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2009 at 6:16 am
Mohit (3/9/2009)
Yaa Jeff go hunt down the 3rd party vendor :). Jeff likes dealing with them hehe.
Man, it just amazes me that people hire consultants/3rd parties without a contract...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 9, 2009 at 10:59 pm
Heh... I didn't say anything about evil intent... I just meant to say the original post is correct... the questions are definitely getting worse and more ignorant.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 9, 2009 at 10:53 pm
... And, if the combination of ID and Countries forms unique pairs, here's another way that's super easy to expand to additional countries...
SELECT ID
FROM #Test
...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 9, 2009 at 10:49 pm
jmucherla (3/9/2009)
TABLE: TEST
ID Countries
100 IN
100 AU
100 GB
100 ...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 9, 2009 at 10:44 pm
Bevan keighley (3/9/2009)
Select t3.ID From #TEST t3 Where t3.COUNTRIES in ('AU', 'IN')
except
Select t3.ID From #TEST t3 Where t3.COUNTRIES not in ('AU', 'IN')
Looks slower based on execution...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 9, 2009 at 10:39 pm
Think not of what to do to the row... think of what to do to the column... and, you don't have to do it all at once... Divide'n'Conquer. 😉
--===== Create...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 9, 2009 at 9:47 pm
You may want to consider loading the data into staging tables first. That way you don't have to worry about such stuff.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 9, 2009 at 9:18 pm
Look closer.... will someone actually have a table name of ['table1, table2']? As it currently stands, this code gives no returns... so what's the actual code and declarations?
--Jeff Moden
Change is inevitable... Change for the better is not.
March 9, 2009 at 9:13 pm
Viewing 15 posts - 44,686 through 44,700 (of 59,101 total)