Walter,

First, let me say that your "DCOM" example isn't doing what you think it's doing. By using CREATEOBJECT(), rather than CREATEOBJECTEX(), you're creating an instance of the object on the local computer, not the remote. The ProgID that you use is used to resolve the actual location of the out-of-process server. This information is stored in the registry. It isn't DCOM at all, but rather simply COM, and the object must be brought across the wire and any data that it accesses must be brought across as well.

Now onto address both of your posts to me.

1. The problem is not ISAM itself, but rather in treating a backend, set-based RDMS as if it were and expecting the same results as one would with ISAM tables. You can't and you shouldn't.

2. In light of the above, the fundamental reason that you can't expect the same level of performance boils down to the required trips across the wire. In an ISAM based application, because of the fact that the application (data engine) is running locally, these are not as big an issue as it is with a server running on another computer that's handling multiple transactions simultaneously.

3. This isn't to say that one can't treat a table on a backend server like a ISAM table. Indeed, in some instances (a flat table with a small number of records), implementation may be easier and the performance may be acceptable. However, in a relational situation or one where the table has a large number of records, it would be a mistake to do so. Again, here it boils down to the number of trips required across the wire.