Hi George,

>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.

It would have been nice if you did your homework a bit better. the dcomcnfg utility allows you to configure on which computer it should run (among authorisation and other stuff). It provides a level of transparency. Therefore the CREATEOBJECT() function either results in creating the object locally or on a remote server. I don't know if this technique has become obsolete, however it seems to work fine in my particular case.

>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.

I see what you mean. Treating a backend-server as a provider of ISAM like tables. Though it can have some applications, generally you want to use either SQL-views or SPT. However I don't recall this being the subjet here.

>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.

For lurkers: See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsqlsg/html/msdn_designeff.asp

George, there is not a single think I disagree with in this post. However I still stand by my standpoint that ISAM itself has nothing to do with the extra trips arround the server. It's just that its often used in a way (network between database and database engine) the extra trips occur.

Walter,