In many ways, SQL Server will be an app server.

With SQL 2000, you will be able to write your own processes using that other white meat - Visual Basic..< vbg >...T-SQL in many ways is a bass-aackward language. VB will be of immense help there...

With SQL 2000, I believe the ability will exist to have one logical SQL Server spread accross multiple physical machines.

Of course, no rule is an absolute. Yes, it often makes sense to not clutter the server with all the work. However, for operations like these, the server is the correct place. If they are 1-time only operations, who cares.

So, with all that said, the scaling issues you bring up, in reality, will not be that significant...


>>If on the other hand, you doing thing things as efficiently as possible, using stored procedures, then ADO/OLE DB is a much faster and a much more efficient way of working with remote data - especially update operations.
>
>Hi John,
>
>PMFJI, I haven't done any work with a true back-end db server and had a question.
>
>If you use stored procedures to do the heavy lifting don't you get stuck with only being able to scale up, ie. throw more RAM and CPU power at the db server.
>
>If you want to scale out, add more application servers to handle the load, wouldn't using sp's make that impossible? I would think you would want all the heavy lifting in DCOM objects on application servers handling that.