Viewing 15 posts - 57,121 through 57,135 (of 59,101 total)
Yep... I realize that my response is a year late, but well done, Chris... Very nice intro to some of the performance measuring tools that are available in SQL Server.
Just...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 25, 2006 at 12:03 pm
Whatever... it's still called a cross-post and will tick off some of the people trying to help because the problem is scattered across 3 posts instead of on a single...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 24, 2006 at 10:07 am
Yeah... kinda... I normally setup a separate database for "staging tables" of large volumes of data being imported. I set the recovery mode to "Simple", as you suggest, and I...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 23, 2006 at 11:00 am
There's no single approach that fits all situations. I've found that there are lots of different factors affecting such a decision... on 24/7 tables, I might use DBCC IndexDefrag because...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 23, 2006 at 9:54 am
Just a note... doing a shrink file may actually kill your performance in the near future... it's going to grow again... it didn't get that big by accident. When it...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 23, 2006 at 7:49 am
Actually... you've posted this nearly identical question 3 times on this forum and a couple of times on other forums. Folks have told you how to do this many ways......
--Jeff Moden
Change is inevitable... Change for the better is not.
December 23, 2006 at 7:45 am
Since the row is automatically deleted after 8 days, I'm thinking it's a combination of a computed column and trigger.... or the trigger just has an update/delete.
I'm thinking that deleting...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 23, 2006 at 7:40 am
The date serial between Excel, VB, and SQL Server vary a bit (a day or two in some cases). And, Excel thinks that 1900 was a leap year... don't use...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 23, 2006 at 7:31 am
Crud... copy and paste error on my part... I didn't include the exec. Glad you got it working and thanks for the feedback.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 23, 2006 at 7:26 am
Sol,
Recommend you post the CREATE TABLE statement for the table with 2,000,000 rows in it and the proc that creates the report. Be sure to include the code for any...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 23, 2006 at 7:17 am
My basic strategy is to avoid using a Clustered Index as a PK if the table suffers a large number of Inserts, Deletes, or Updates to the PK columns because...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 22, 2006 at 11:33 am
Doesn't matter what YOU can see... what can the SERVER see? The server must be logged in as a "power user" that can see shares and machines. In Enterprise Manager,...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 22, 2006 at 11:17 am
Anytime you try to put a row source or a table name in a FROM, you must (unfortunately) use dynamic SQL...
DECLARE @sql VARCHAR(8000)
--Jeff Moden
Change is inevitable... Change for the better is not.
December 22, 2006 at 11:09 am
The "app" cleaned it up... the number is still stored in the db with the inaccuracy.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 22, 2006 at 9:46 am
Before you start using table variables... study Q3/A3 and Q4/A4 of the following link...
http://support.microsoft.com/default.aspx?scid=kb;en-us;305977&Product=sql2k
...and, yes, there can be a huge difference in performance... because table variables do not use...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 22, 2006 at 9:38 am
Viewing 15 posts - 57,121 through 57,135 (of 59,101 total)