Jeff, usually we're on the same page and see eye to eye on things, even if we prefer to do them in different ways, but in this... you have me boggled.

Why would you ever want to involve drive I/O and third point of failure (file system) in sending easily transmitted data? Besides the fact that I don't BCP without significant need (xp_cmdshell signoffs and the like), and it's normally a one-shot item based on the initial parameters (so nothing I'd want persisted), I still don't understand. For user initiated persistable requests I use SSRS, for automation and archiving I use BCP/SSIS (depends on what makes most sense, usually SSIS in my current environment). For data communications? I don't understand that.

EDIT: Also, it's not similar to replication, just offhand, not remotely close for the scenarios I have in mind. If I have 10 users sending down simultaneous requests, each one ends up with a different shipment. Scenario: Local system has the necessary columns to properly deal with half the where clause, along with say a date range to get data for. Using those IDs and ranges from the return against a foreign system's significantly reduces the data coming back from the link.

Two approaches: Either you ship the requested filtered list over to the linked server so it can use it, or the linked server has to call back to the local (thus, loop the loop coding) to get its filter. I prefer to ship first. Each user can be doing this with completely different parameters, thus different lists.

I just want to make sure we're thinking about the same scenario(s).