The biggest issue is software versus hardware design.

For background (and, as you probably already know), an application, via SQL client interface sends a request to the SQL server.

The SQL server finds the records, creates a record set, and sends it back to the client.

This is (usually) an improvement over the old system of sending every record, one-by-one, to the requesting client so the client can do its own selection.

Now, here's the probably issue (if any):

If the DB server is remote, and the database is remote, and the client is local ... and the application programmer permits search/selection parameters that are too broad, you're gonna be pumping a huge record set across the WAN link.

The other variation is that the DB programmer writes an overly broad Stored Procedure (a function associated with the database & DB engine that an application can call) will also result in an massive record set transiting your WAN link.

IF possible, you should check with your programmer person to make sure they set limits on the record set size returned from a query ... or AT THE LEAST provide the user with a warning that "2,300,000 records will be returned from this query, proceed?" kind of statement.

Because once that much traffic starts flowing, there's usually only a few, extreme, ugly ways to kill it.

It is generally safer, and (if you're paying payload or have a low CIR) cheaper to put a terminal server (i.e., Citrix or Microsoft Remote Desktop, or a *nix box and X-windows) at the remote (home office) site and run the application remotely.

That way, only screen & keyboard traffic ever crosses the WAN, application & database traffic stays on the same LAN.

Even if the App or user creates a massive dataset, the LAN @100Mbps (or Gig) can handle it much better than a T1/E1 or couple megabit DSL or BB connection.

You can run Remote Desktop or a Citrix client through dial-up if necessary (not desirable, but functional)

Pumping massive data across a WAN should be your last option if possible.

Good Luck

Scott