Viewing 15 posts - 56,461 through 56,475 (of 59,069 total)
25,000 tables... 20-25 gig of default data... how big did they make TempDB in total (I realize you have it partitioned)?
--Jeff Moden
Change is inevitable... Change for the better is not.
May 8, 2007 at 7:19 am
Just one more question... why spreadsheets... why not print reports?
--Jeff Moden
Change is inevitable... Change for the better is not.
May 7, 2007 at 8:48 pm
Nice gesture... but a really, really bad thing to do...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 7, 2007 at 8:40 pm
I think you mean that trailing spaces are neglected...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 7, 2007 at 8:31 pm
Spot on, Serqiy!
--Jeff Moden
Change is inevitable... Change for the better is not.
May 7, 2007 at 7:49 pm
Documentation? ... ... Documentation??? ... ... DOCUMENTATION!!!! Now THAT's what I'm talkin' 'bout!!!
Very nicely done, Alain!
--Jeff Moden
Change is inevitable... Change for the better is not.
May 7, 2007 at 7:37 pm
Didn't know SAP made a version for SQL Server... that's cool. Gotta look that one up.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 7, 2007 at 7:09 am
Then you can write a stored procedure that figures all that out (provided CATEGORY is used in a normalized fashion) and DTS the results of the stored procedure or put them...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 7, 2007 at 6:57 am
Yep... no database should ever be set to autogrow by 10% including TempDB... Estimate the maximum size you'll need for the next six months (or a year), add 20%, and...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 6, 2007 at 8:41 pm
Not entirely clear on what you want to do... do you have data in SQL Server that you want to spool out in a similar fashion? In other words, where...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 5, 2007 at 8:48 am
If you use Enterprise Manager to join many tables with outer joins, it will frequently produce both LEFT and RIGHT outer joins. It will also, on occasion, produce joins that...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 4, 2007 at 8:09 pm
If all of this is happening in an explicitly declared transaction, that would be the source of your problems.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 4, 2007 at 5:54 pm
And then, examine the code... most performance problems have nothing to do with the hardware and sometimes not even with indexes. Got cursors? Got WHILE loops? Got views with aggragate...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 4, 2007 at 5:39 pm
PLEASE... take the time to show some data before and after the function gets done with it... it sounds like you want a table function but we can't tell for...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 4, 2007 at 5:28 pm
David's solution is almost correct, but not quite... the resolution for DATETIME datatypes is 3 milliseconds... David's solution rounds up to midnight... you need to do this instead...
SELECT...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 4, 2007 at 5:25 pm
Viewing 15 posts - 56,461 through 56,475 (of 59,069 total)