Viewing 15 posts - 54,946 through 54,960 (of 59,098 total)
Heh... at least you said "set"...
Ok, thanks, guys... I've gotta study this a bit. ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
September 21, 2007 at 8:15 pm
Ummm... "monitoring" is great... helps you identify crap code that takes days to run without finishing... but, unless you take the next step, you might as well not waste your...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 21, 2007 at 7:59 pm
| Hi, I want to copy production database to a testing server. The production database is too... |
--Jeff Moden
Change is inevitable... Change for the better is not.
September 21, 2007 at 7:36 pm
Wouldn't have a problem at all if the HD's were labeled correctly as HD1, HD2, HD3, etc ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
September 21, 2007 at 7:24 pm
Here's the corrected query... since I don't have the tables available that you do, I'm unable to test it, but it should be close. Combine that with the suggestions others...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 21, 2007 at 7:19 pm
Heh... damned straight it's slow... you've written it as you would in Oracle... you've used a "Correlated Subquery" in the SET clause and that means that the query must be...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 21, 2007 at 7:01 pm
Unless the worksheet is protected against mistakes like adding an unexpected column or hitting the space-bar to "delete" data, you may get some wildly unexpected results and failures using Excel...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 21, 2007 at 6:51 pm
You actually expect an Access ODBC driver to operate as fast as an SQL Server OLE DB driver when used against SQL SERVER?
...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 21, 2007 at 6:46 pm
Heh... I have to laugh at what they call "best practices" for most performance issues... no where do they say "review all code for possible performance issues before it goes...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 21, 2007 at 6:43 pm
Can you post the code for your final solution, please?
--Jeff Moden
Change is inevitable... Change for the better is not.
September 21, 2007 at 6:35 pm
Thank you for the feedback and I have a very high speed solution in mind... but I need to know what you want done with the data that I posted......
--Jeff Moden
Change is inevitable... Change for the better is not.
September 21, 2007 at 6:05 pm
First, no need for a cursor in triggers... ever! You can simply join to either the INSERTED table, the DELETED table, or both.
Second, I recommend that you do NOT log...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 21, 2007 at 6:01 pm
Ya gotta love those that don't even try the suggestions given... guess these "experts" can just look and see "bad code" ![]()
I'm not sure...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 21, 2007 at 5:51 pm
Last, but not least... security... everybody can make a table in TempDB... might not be true on the "given" DB for whatever user the sproc is logged in as...
AND, TempDB...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 21, 2007 at 5:47 pm
No, pretty sure there's nothing built in... you'd have to do a SELECT INTO a temp table and then read the datatype from the columns something like this...
...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 21, 2007 at 5:17 pm
Viewing 15 posts - 54,946 through 54,960 (of 59,098 total)