Viewing 15 posts - 56,311 through 56,325 (of 59,098 total)
![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2007 at 7:26 am
Absolutely agree with that!
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2007 at 7:21 am
Now, wouldn't it be an absolute hoot if they were looking at the MSDE box in Query Analyzer or EM thinking that it was the production box? Not so uncommon a...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2007 at 1:31 am
Concur... that's just about the same as what I use for header info. And I document any parameters where such documentation belongs... next to the parameters in the code --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)
May 30, 2007 at 1:23 am
Heh... cursors... gotta love 'em.
How much disk space do you have... 300 gig? 500 gig? Why are you worried about a 9 or 10 gig TempDB? Shoot... we preset ours...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2007 at 1:15 am
Why speculate
Do a test
Run the following code several times and tell your team mate "Sorry,...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2007 at 1:04 am
That certainly doesn't help the rest of us... Please post the "e-mail w/ example" here ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2007 at 12:27 am
Just like anywhere else... build a calendar table and a separate holiday table... include holidays for every country and make sure the holiday table has the ISO country code in...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2007 at 12:25 am
Dinendra,
We need to know why you want to do this so we can give you the most correct answer.
(Thats' why, Ben
)
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2007 at 12:14 am
You might be able to use some form of recursive CTE in SQL Server 2005, but your request is in an SQL Server 2000 forum.
The UDF that David suggested...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2007 at 12:03 am
I am amazed at how many applications I see with a stored procedure that has a single record... |
--Jeff Moden
Change is inevitable... Change for the better is not.
May 29, 2007 at 11:53 pm
...and, if there hasn't been too much activity, you may be able to recover the MDF and LDF files if they were, in fact, deleted.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 29, 2007 at 11:33 pm
Add an Identity column and delete the dupes when the import is done... much faster than trying to build an "UPSERT" (merge) in SQL Server 2000.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 29, 2007 at 11:31 pm
Here, here and well said. Thanks, Matt.
Steve, thanks for taking the time to remember veterans and for paralleling the "give" and perils of good people in the world of IT. A...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 29, 2007 at 11:25 pm
Ah hah!!! THAT's why my checkbook is a mess! I used Kerchoff's law of voltage dividers as applied to a WheatStone Bridge instead of the good ol' Boltzmann factor k --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)
May 29, 2007 at 10:53 pm
Viewing 15 posts - 56,311 through 56,325 (of 59,098 total)