Viewing 15 posts - 54,256 through 54,270 (of 59,072 total)
Nili S (11/7/2007)
.... And it worked!! For both Oracle and SQL Server.Thanks!
GETDATE() worked in Oracle? I don't think so...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2007 at 7:10 pm
I agree with Mayank... just to add to that, the != will actually appear in execution plans as <>. Sounds strange, but I can always tell who wrote the...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2007 at 6:18 pm
Why not just make it an auto-exec macro that get's executed when the spreadsheet is opened?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2007 at 6:09 pm
But we are using 'OR' which could generate cartesian product.
Ok, Karth... your turn to explain something... How could the use of 'OR' cause a Cartesian product?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2007 at 6:05 pm
Absolutely nothing... NOT IN is evaluated to <> for single values and some exclusionary AND's using both for multi-values.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2007 at 6:03 pm
Matt Miller (11/7/2007)
Regular expression CLR functions would do that as well.... But you still need a search string...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2007 at 4:31 pm
brendt hess (11/7/2007)
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2007 at 4:19 pm
karthikeyan (11/5/2007)
Update yourtablename
set add1 = ''
where add1 is null
Now execute your code, it should work
do You know why are you getting 'NULL' Values...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2007 at 4:16 pm
I sure as heck can not figure out how to do that. When I try to copy code into QA when someone used the blocks like I did, it...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2007 at 4:14 pm
brendt hess (11/7/2007)
Must remember to post my code in a quoted block, so that formatting is retained.
Problem is, if you copy from the code block to query analyzer, it really...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2007 at 4:13 pm
I believe that PATINDEX is the only function that will do as you ask on TEXT datatypes.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2007 at 8:09 am
Heh... and the Oracle notation is backwards from the T-SQL notation... in Oracle (+)= means "Right Outer Join"... in SQL Server, *= means "Left Outer Join". If you believe...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2007 at 7:57 am
My Questions :
1. Whether the numbers used in this query are constant or not ?
2. Can you explain me the logic of this number ?
3. Can i use any numbers(for...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2007 at 7:42 am
karthikeyan (11/7/2007)
I am using sql2000. Both gave me the same output.
Yes... for simple queries they will work the same... for not so simple queries with many criteria, *= will surprise...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2007 at 6:32 am
The answer is, no... Within a given SELECT, Rand is not RAND unless it has a random seed... the only thing in SQL Server that even comes close to being...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2007 at 6:25 am
Viewing 15 posts - 54,256 through 54,270 (of 59,072 total)