Viewing 15 posts - 53,281 through 53,295 (of 59,072 total)
Heh... see that! Another good answer that wasn't in the possible answers :hehe:
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2007 at 2:57 pm
1. is the table locked during the export?
2. what if at that particular moment i have hundreds of new inserts?
3. what would be the best...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2007 at 2:56 pm
I don't know what this table is actually for, but it's generally a bad idea to just flush data down the toilet without carefully considering what that loss of data...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2007 at 1:31 pm
I absolutely agree with Sergiy and Madhivinan... the root problem is that the column is the wrong data type. The datatype for the column should be/must be changed to...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2007 at 1:28 pm
This whole thread and the original concept isn't something I would even consider doing... First, there may be a GUI out there that you don't know about that requires those...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2007 at 1:23 pm
No, it's not possible using BULK INSERT.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2007 at 1:13 pm
raym (12/28/2007)
How can I speed this up ?
Ray, the title of your post hit the nail on the head... get rid of the cursors, plain and simple. I'm not...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2007 at 1:10 pm
... and PLEASE DON'T DOUBLE POST!!!!
http://www.sqlservercentral.com/Forums/Topic436570-338-1.aspx
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2007 at 1:05 pm
... and PLEASE DON'T DOUBLE POST!!!!
http://www.sqlservercentral.com/Forums/Topic436572-338-1.aspx
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2007 at 1:04 pm
The REAL question would be, WHY are you using a cursor for this? You should be able to do this in a setbased fashion...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2007 at 1:02 pm
have about 2,00,00,000 records in a table which are being queried.
More over I have 2 more tables of same specs mentioned above.
Queries are taking lot of time. usually...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2007 at 12:58 pm
Heh... I got the answer right but the real answer isn't one of those listed. The question is "What must he worry about when using the @@FETCH_STATUS function in...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2007 at 12:52 pm
Ok... another way to do it would be to export the data to tab delimited files on some common file share and use BCP or BULK INSERT to import the...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2007 at 12:41 pm
Dunno about most... I'd simply make linked servers and have a proc read the data in. Don't want to make a single view because if one of the servers...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2007 at 12:16 pm
Heh... a While loop... "Firehose" cursor would be just as good... take a look at the function I made in this thread... no explicit loop... no cursor... still basically hidden...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2007 at 12:10 pm
Viewing 15 posts - 53,281 through 53,295 (of 59,072 total)