Viewing 15 posts - 51,406 through 51,420 (of 59,098 total)
Matt Miller (3/31/2008)
Jeff Moden (3/29/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 7:52 pm
srienstr (3/31/2008)
Daniel Wilson (5/22/2007)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 7:39 pm
Thanks John G... and spot on... the hard part most certainly is getting developers and designers to think in correct set based frames of mind... Sometimes that even includes SQL...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 7:33 pm
Wayne West (3/31/2008)
I agree, performance isn't as big of a deal as it was back in 4.x/6.5 days.
Perfect... everyone keep thinking that way... keeps me employed fixing performance problems...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 7:24 pm
rbarryyoung (3/30/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 7:18 pm
Robert (3/31/2008)
Considering the level of the question, I wouldn't think so either. However, when dealing with customers or assisting fellows developers on...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 7:06 pm
Buxton69 (3/31/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 7:03 pm
escaleraroyal (3/31/2008)
go some dataParty table
-----------------------------------------
instrument_id party_id last_name first_name middle_name name_suffix
31966558329324CLUBBSTACYL
331891810350608CROOKE,BESSIE J EST
331891810350858JACKSONLLOYDD
output
-------------------
instrument_idparty_idsort_orderparty_data
319665583293241(I) CLUBB, STACY L
3318918103506082(I) CROOKE,BESSIE J EST
3318918103508583(I) JACKSON, LLOYD D
Is there a question that goes along with this...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 6:56 pm
AlexSQLForums (3/31/2008)
Thanks for input everyoneI used:
if update (columnname) or update(columnname) or update (columnname)begin
--sql statements
end
and it worked
Thanks for posting your solution, Alex!
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 6:51 pm
Cory Ellingson (3/27/2008)
I just checked the SQL Log File Viewer, and I see auto grows being logged..Is this what you are looking for?
Cory... I've not had to use the SQL...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 6:40 pm
Thanks, Brian...
Just so everyone knows, sp_track_db_growth does not even come close to what the OP asked for. Rather, it tracks what size the backup files are. It does...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 6:13 pm
He's all your's, Barry 😉 Send him an email 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 5:08 pm
Babu_Raj (3/31/2008)
EXEC sp_track_db_growthGO
I agree... such a sproc is NOT provided by MS in any installation of SQL Server 2000... would you post the code for this sp_track_db_growth sproc that...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 5:06 pm
... and, no matter how you shape it, a cursor or While Loop is going to kill performance.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 5:02 pm
Heh... understood. Been there and done that. Not fun no matter which way you do it.
I agree with most of the others... log shipping is probably the best...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 4:58 pm
Viewing 15 posts - 51,406 through 51,420 (of 59,098 total)