Viewing 15 posts - 51,406 through 51,420 (of 59,091 total)
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
Andre T (3/31/2008)
So, basically, I do need the trigger to call my stored procedure for each item changed.
Absolutely NOT! That's RBAR on steroids and it will crush any hope...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 4:54 pm
Lots of great ideas on this thead...
At this point, I'd have to say "it depends"... like has already been said, both UDF's and Views can be written in horribly incorrect...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 4:49 pm
Ahmad Osama (3/27/2008)
souLTower (3/27/2008)
-- Remember to use procs to eliminate SQL injection
SELECT cid from CompanyNames where cname = [user...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 7:06 am
In almost all cases, neither a cursor nor any form of a While loop are required especially in SQL Server 2005.
Lots of folks use the guidline "when it can't be...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 7:02 am
It would be much more effective to output your data to a file and use Word to do a MERGE document.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 6:53 am
Heh... Gail is spot on... and it ticks some of us off so bad, we won't respond with anything useful.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 6:52 am
On the subject of "Derived Tables", look into CTE's... they make for easier to read code and can be self aliased, if need be, without duplicating the "sub-query".
Also, take a...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 6:50 am
Viewing 15 posts - 51,406 through 51,420 (of 59,091 total)