George,

I want to stress here that only want to make clear that the terms 'ISAM' and 'set based' in itself have totally nothing to do with trips across the server.

>>No, I'm talking about an out of process server that is started at the server (DCOM), Only the object is openen on the client. All commands in a specific method called from the workstation are processed by the server, not the workstation. So if I call a method it and pass a SQL command, it gets processed on the server, rather than on the workstation. Only the command (and some administarional data) crosses the network.
>
>ROFLMAO! That's the funniest idea I've heard in a long time. Remotely connect to a VFP Automation Server via CREATOBJECTEX() and have it do the lifting.

Createobject() would do also.

>Hahahaha. I guess you can do it, but the question that immediately comes to mind is "Why would anyone in their right mind do it?" I mean, afterall, you have to create an interface so that the client could access and modify the dataset.

Hmmm, wasn't XML the glue between such tiers ? (after all we're talking about tiers here).

>Further, VFP isn't and can't produce any free-threaded exes or dlls. Even an MTDLL is Apartment model threaded. What happens when more than one user tries to access it? Whoops, methinks there might be just a tiny problem.

If this would be true, what is all the fuss about creating data intensive middle tier objects (e.g. in webservices) ? After all, all I did was creating a middle tier object here. I'm not sure freethreading has anything to do with this one. Basically you're saying that VFP is useless to create middletier objects here.

In what way is my example different than creating middle tier objects in webservices ?

>Yes, in VFP, but SQL server is different in that there may be one or more pages involved. Nevertheless, I've kept point to trips back and forth across the wire, that's where the bottlenecks can occur. And that's where the advantage lies distinctly with a backend, set-based server.

This has not have anything to do with a SET-based server. This applies to any kind of backend database server.

>>So why do we have multithreaded Dlls within VFP ? Using COM+ I could build the same in VFP with respect of handling multiple transactions at once.

>They're not truly multi-threaded, they're aparament model threaded. If you don't believe me, build one and check the threading model in the registry. That'll tell you.

I wonder what the practical difference are, see above

>>Aha.... now we've got a point. Yes, ISAM tables are often used from a file server while the database engine itself operates on the workstation. However, this has nothing to do with ISAM itself, but rather what data strategies you could employ with it.
>
>Yeah, it does and I've commented before that it's a mistake to treat a backend server like SQL Server in the same manner. You can do so if you want a bad application.

So we agree that this has nothing to do with ISAM itself ?

>>Ehhhh, I don't get it. How much different is a VFP record pointer as a filepointer used for positioning before an update ? Of course SQL server also has to lookup the modified records (with a filepointer) and update it. In what respect is VFP different here ?
>
>I'll sum everything up at the end.

>>I'll agree you don't have ultimate control about how much is downloaded into memory, but you definitely have SOME control. When openening a VFP table, only the header and the first few records are downloaded into memory. If you do a query the number of downloaded records depend on the the command you gave (SKIP would require at most one record, if no filer is in effect), on rushmore (If a query is fully optimized) only the required records are downloaded into memory etc. In SQL server internally a comparable thing is happening (but then the records are requested from disk directly, in stead of from a fileserver).
>>
>>All is a matter of abstraction. As in my example of the VFP (DCOM) server, I could do the same. From an application I could send a command to the DCOM application, which processes my command and send me back my result. In what respect does ISAM or being record or set based have anything to do with this ? Nothing.

>There are inherent differences in the models. To say otherwise shows a lack of understanding them

Of course there are differences in models (what level are we talking about ?), but when you look at the internal storage retrieval and storage mechanism in terms of I/O, you'll see that every aspect of retrieving and updating records have more simularities than differences. The BIG difference is that in VFP where the phisical database is seperated from the database engine by the network, these I/O becomes painfully visible (and messurable). IN SQL server, however, since this is all encapsulated into one server DBMS it is not as visible, but don't forget more or less the same I/O is happening in this respect.

>>How about webservices: If i've got a client connecting through webservices to a VFP database or a SQL-server database. How would this influence communication ? Not ...., both can accomplish the same task. Whether the backend is based on ISAM or not, or being set or record based, does not make any difference.

>>Again,in this example this is because the database engine is seperated by the network from the actual database. If you'd be able to split the database from the database engine in for example SQL - server, you would see even more trips across the server because more I/O has to be done.

>Right! And that's the point. You wouldn't try to implement client/server with a backend with the data engine on the client if you aren't willing to put up with the inherent bottlenecks.

O.K. We agree, so what does this have fundamentally have to do with ISAM ? Nothing....

One more example. The Jet database engine is regarded to be NON-ISAM, since like in a lot of backend-DBMSs all is in just one databasefile. However, it is both record oriented, and has the same characteristics when talking about the occuring trips around the server when updating records. Another prove that this has nothing to do with ISAM itself.

>Your DCOM exmaple isn't a very good one.

I think you should reconsider this statement, see above about middle tier objects.

>Further, the comparison between an ISAM type data engine like VFP and a set-based backend server, such as SQL Server, is perfectly valid in the context of the basis for my statements.

Then I doubt that your 'context' is a fait and valid one.

>With VFP working against VFP data on a server, VFP has to make more trips back and forth across the wire than does a properly designed VFP application working with SQL Server. This, Walter, is fact and as such is not subject to debate. If you choose to disagree then you don't understand what's involved.

Here again you make a non valid comparison. Split the VFP application up into three tiers:

1. One tier for the front-end executing at the client.
2. One tier for the middle tier (emulating the SQL server engine) executing at the server.
3. One tier for the VFP database. (emulating the SQL server database) stored on the server.

And yes indeed, I managed to reduce network trafic at the same level as SQL server, while I used a record oriented ISAM based database. Conclusion ? .....

I'm not going to argue if this specific implementation is usefull, however you could easely think of many applications (internet based) that justify three tiers. As widely known VFP can play a part in all three layers.


Bottom line .........


The only conclusion I draw is that being ISAM or NON - ISAM, being set oriented or record oriented has nothing to do with trips around the server. People think they're related because ISAM and record oriented solutions are often (but not exclusively) implemented in such manner that more trips around the server occur.

I've tried to point out that trips arround the server can be reduced with ISAM based solutions, and that NON ISAM databases can suffer from the same problem (Jet engine).

If you disagree with this conclusion, I think its you don't understand what you're talking about.


Walter,