If you're building a report you should be working with a reasonable set of records and 5 million rows is far from being reasonable, so you need to cut it...

I keep on getting the same kind of error with HitOLEDB provider for AS/400. I had to refactor all my queries with four-part names into OPENQUERY to get rid of...

I don't think you really want to process 5 million rows on the client side, especially if you're building a report. Store the results of your SP in a temp...

I'm sorry, I was wrong about the trace flag, beacuse it only applies to databases on UNC path. You can read this if you want some more information: http://www.sqldba.org/articles/43-sql-server-database-on-UNC-network-drive-trace-flag-1807.aspx.

For your...

I completely agree with David. I didn't see his reply and I ended up saying the same things.

Gianluca

Yes, it's true, but costs are relative and a cost of 0% doesn't mean the operation comes for free, especially in a...

I see lots of table scans: can't you get rid of them with some kind of index?

Are you trying to restore from a mapped network drive or from a UNC path? Remember that the mapped network drive is visible only to the user who did the...

You'll find many resources on SSIS (Sql Server Integration Services) on this site as well. I think this could be a productive approach, but I don't know exactly your needs...

For sure checking the two tables for differences will slow down your application, especially if a remote table is involved. You could set up a SSIS package to propagate the...

I never used varchar(max), but this seems to be a nice feature in SQL2005.

This is from BOL:

Use char when the sizes of the column data entries are consistent.

Use varchar when...

Ifyou have to update the local table (let's say table A) according to the changes in the remote table (table B), maybe you should do the opposite: link the server...

Well, I'm no LUN expert, I can only tell you what I'm successfully doing with my configuration:

I have a 6 node cluster server with 9 instances. Each instance points to...

I don't see why a server should access a LUN holding data it doesn't need. There's no performance or security emprovement in doing that. I would keep each LUN reserved...

I didn't understand completely your question, but it seems to me you are trying to update a remote table on every update to the local table, using the primary key...