Viewing 15 posts - 59,056 through 59,070 (of 59,102 total)
/* 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
In that case, Bulk Insert has a MAX ERRORS setting that works just like the BCP -m parameter. Again, check BOL under Bulk Insert.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 23, 2004 at 9:06 pm
No execution plan is formed for Dynamic SQL until Runtime regardless of method of execution.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 23, 2004 at 5:53 am
Not sure but I think it may be the way that Crystal is using the view... I believe that it creates a different instance of the view for each instance that...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 22, 2004 at 7:34 pm
Kokyan gave a good example of "Dynamic SQL"... just wanted to remind everyone that dynamic SQL can be quite a bit slower than "Static SQL" because it does not pre-form...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 22, 2004 at 7:24 pm
It's a forum, not on-line help... ![]()
Anyway, use the -m parameter followed by the number of errors you wish to allow. Lookup BCP,Overview in...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 22, 2004 at 7:20 pm
1. You need to assign a "table alias" to the SELECT in the FROM clause.
2. You need to use that table alias on all column names to the right of...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 21, 2004 at 5:03 pm
Viewing 15 posts - 59,056 through 59,070 (of 59,102 total)