Viewing 15 posts - 59,011 through 59,025 (of 59,063 total)
Howdy,
It is and always has been a "bug" with Enterprise Manager. I don't think you'll find a fix for it even on the Microsoft site (I've look for this fix...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 1, 2004 at 6:10 am
Steve,
To answer your first question, I've found that PatIndex is a wee bit faster than LIKE. In either case, both take a toll on speed when it comes to large data...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 1, 2004 at 5:57 am
My thoughts are that if you are trying to import data that is either delimited, fixed field, or a combo of both, you should probably take the time to use...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2004 at 10:04 pm
Sometimes ya just gotta do with the data ya got...
The REPLACE answer is a good one. Thanks.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2004 at 9:44 pm
SELECT * FROM DBO.pt_vCheckSupport
WHERE supp_startdt>='07-MAR-2004' AND supp_startdt<'20-MAR-2004'
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2004 at 9:32 pm
The PATINDEX example works. Try it.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2004 at 8:24 pm
/* SET NOCOUNT ON */
SELECT GEO , CustomerType, --Jeff Moden Change is inevitable... Change for the better is not.
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
April 27, 2004 at 9:28 pm
Got the same result... no error but no change. Thank you for trying.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 26, 2004 at 11:10 pm
>(select count(*) from myview where ...) as field1
>(select sum(field) from my where ...) as field2
Your last post said that you used aggregate functions for each field. Looking at the code...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 25, 2004 at 9:27 pm
First, thank you for the table and data code...
always a pleasure to NOT have to write code just to do a test setup...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 25, 2004 at 7:55 am
A.zcmSBA_V_WONO=B.zcmSBA_V_WONO AND
A.zcmSBA_N_JONO=B.zcmSBA_N_JONO AND
A.zcmSBA_V_TRXNO=B.zcmSBA_V_TRXNO
--Jeff Moden
Change is inevitable... Change for the better is not.
April 25, 2004 at 7:10 am
Worse than that, it's been my experience (in SQL Server 7) that a SELECT such as yours will create a separate instance of the view, in memory, for each named instance...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 25, 2004 at 7:02 am
Kokyan is correct... temp tables are always unique per session. You can see the actual name of a temp table in the tree view (press f8) of Query Analyzer. They...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 25, 2004 at 6:35 am
Actually, there is! It comes in the form of the PARSENAME command which was specifically developed to break apart the parts SQL object names "at the dots". Since your example...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 24, 2004 at 9:04 pm
Thought AH did a pretty good job! ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
April 23, 2004 at 9:20 pm
Viewing 15 posts - 59,011 through 59,025 (of 59,063 total)