Hi George,

Hey, hey, don't take it personal body...

>Let me make one thing perfectly clear about one of your statements above. I do know for a fact that you cannot use CREATEOBJECT() to create an instance on the server and, secondly, that MTDLLs are Apartment model threaded and not free threadaed. I suggest you check your facts before questioning my statement. It's absolutely clear that you don't know what you're talking about here.

I don't care about the difference in this example, I'm aware three threaded solutions scale much better, but this is not the issue. My dcom example is just what it is an example, whether it scales or not. The example serves the purpose to shift the network I/O to another tier, so it becomes less an issue.

Emphasizing the usefull- or uselessness of this example is just distracting from the issue: "ISAM itself has nothing to do with trips around the server."

>In the instance of VFP databases and tables residing on the server, anytime a table is opened, it requires that, at least a portion of the data at a minimum, be sent across the wire. Further, in the instance of a compact/compound index exsisting, it requires that information regarding that also be sent across the wire.

I already agree to this. You're not listening.

>Assuming an SQL statement, at best, VFP has to load the appropriate index, which is one trip, then request the specific records matching the WHEN clause across, which is another.
>
>In the instance that no index tag matching the criteria exists, VFP may be forced to build such. This is from the documentation. If the previous statement is true or false is irrelevant. In either case, VFP is forced to retrieve every record from the server to see if it matches the criteria.
>
>If records are updated they must be sent back across the wire, one by one. If the update requires a change to the index, that too must be sent.

Again, I fully agree with this as I agreed in earlier posts.

>With a set-base backend server, such as SQL Server, no such trips apply. You request data matching the criteria. The server sends back the matches. When the client updates the records affected are sent back across the wire once. SQL Server takes care of the rest .

Here again, I stress the point you're not making a valid comparison. There are DBMS products avaliable that are set-oriented where the physical database can reside somewhere else than the database engine. They're not ISAM but also suffer from the trips around the server.

>My reaction to your DCOM solution is simply based on the fact that it doesn't scale. Everytime a new user accesses the out-of-process server, a new instance of it will be created on the server. Rather quickly, the server will run out of memory.

Ever heard of "multi use" out of process servers ? I've used that in several project for reducing network trafic and runs fine. However, these servers don't have to scale to a high level, so any issues about apartment threading versus free threading is not applicable here.

>This is one of the reasons why Foxisapi.dll is free rather than apartment model threaded. That dll is not written with VFP.

Thanks for the info, I'll keep that in mind.

However, our discussion seem to be pretty useless as you insist to compare two different things on two different abstration levels. I agree (from the beginning) that ISAM is often used in situations where indeed extra trips arround the server occur. However I tried to point out this is not the fault of ISAM, but rather how you use it. You can use it other ways so that trips around the server don't occur (Multi tier applications).

On the other hand I tried to point out that NON ISAM database can suffer from the same problem depending on where the physical database is stored.

In my tier example I tried to point out I could build a database server that returns set oriented results, but the internals are based on ISAM. This way you can avoid the trips around the server.

I see that in this discussion there is nothing to gain since we're essentially agreeing on the same things, but rather have different viewpoints of either the definition of ISAM, comparing it with other DB access strategies and the abstration level of comparison. It does not make a big difference here who is right and who is wrong. Futher discussion is only a waste of time.

Lets leave it with, agreeing to disagree on the statement whether or not ISAM always causes extra trips around the server. I think no-one realy cares as long as its clear when the extra trips around the server occur. In this respect we seem to agree.

Walter,