Jim,

It is my personal opinion that the answers to your questions cannot be found in any books, nor that anyone just will come up with the answers; it's too complex.
Another thing is, that any sole subject (which will be in books (etc), won't give the answer on combinations (always being there);

Like you stated in some other thread "we don't know about the kernel of things" (those kind of words), and that may be true already because of nobody is able to know about it all. However ...

I disagree on your statement I just quoted;

Once a situation (in certain combinations) is running, it is not too hard to "test" upon these kind of questions, once one has the skill to interpret 100 % well what is going on. That it is very hard to get this skill, is IMHO prooved by not knowing any person of whatever instance approaching this matter in a way I personally can't shoot at. So I imply that I can, and why not. It is my hobby for about 25 years with f.e. as a result that there are very few bits and bytes I can't "guess" from Fox's kernel.

In the end I sadly still can't help you with the answers, because subjects are involved I'm not enough experienced on, and answers can only be given on the (specific) combination of all.

Small example, being rather off topic, but to indicate how difficult life is :

I think we all (?) agree that ODBC is slow phenomenon, better to avoid at all. So, a given fact ? yup, as long as some highflyer puts it in a book or article, this is accepted, until another prooves (!) this is not true. Now assumed that nobody gave this counter-proove so far (I don't read that much ...), we accept it as a fact. So, for ten years or so, I did too;
A half a year ago I started my first MySql activities and couldn't so much believe what I saw with respect to the performance of it. This was just super-fast and via ODBC of course. So what is the matter here ?

1. ODBC is not that slow factor at all, or
2. MySql is that much faster than native VFP-table access that ODBC-slowness doesn't count, or
3. Everybody up till now looked wrong at the subject.

What this comes to, is that this is my "judgement" after one small trial and 30 minutes work, concluding that I won't believe anything from hear-saying until I've prooved it my self. And well, this is already me, being the most ignorant on mother earth.

After this 30 minutes of work I stopped on the subject because of external circumstances, and I think I just promised this work to be continued in due time (ref. VFP8 wish);
For now however, you sort of confront me with it again, making me put the next theory
Everyone using ODBC will be using SQL as well;
In my own experience, letting SQL go on just VFP tables, this isn't fast at all (read : slow), though depending on what exactly is being done.
So, what I guess (for now !) is that where ODBC is being interpreted as slow, it may be just VFP's SQL being slow.
It is not hard at all to work this out further, by separating the SQL somehow from the ODBC-response. Once this has succeeded, I will know it and didn't read any book or article. Note that finding the book etc. will take more time than this small test ...

To emphasize some further on the impact on the combinations, here another small example :

Why is the access of native tables over a network is always -let's say- 10 times slower than the same locally ?
Though many will know the exact answer, many more won't;
All records read from the server will internally perform an RLock (no matter what DB-command is being used), implying an interaction between the server and the client per record while communicating at this level originally is at block-level (containing let's say 50 records). Well, that's a loss of time huh ?
Too proove I'm right, just open the file exclusively, and you won't notice a difference anymore with the locally accesed table, but the difference on the speed of the network which has to transfer the block (4K - 64K depending on the settings for that), giving a sweep of a burst of f.e. 64K at one time, leaving the rest to the client's cache; the network is assumed to be slower compared to the client's (PC's) disk-subsystem.
Now this has to be places in some perspective too, since the PC nowadays is multi-tasking (Win), and the RLock-principle is workingh out there just as well. Now when the PC's local disk is not used multi-tasked (I can't guess why) the local file has to be opened exclusively, otherwise the test won't give the proper results ...

So real proper testing is not easy, but is once you yourself evoluted to some (no much) basic knowledge, to extend and extend, and used into the next experience ...

To complete these rather off topic lines, I'd like to map the last phrases onto the ODBC-thing and "know" that the (remote) MySql DBMS for sure doesn't apply the RLock-thing per record. It just doesn't work like that in there. So this leaves us with a vote for option 2 on my 1-2-3 list from the beginning : the being 10 times more fast of the remote SQL DBMS on the aspect of RLock only (!) masks the slowness -if there- on ODBC. Add to that my expectation on VFP-SQL itself being slow, and what's the expression on ODBC being slow worth ? not 1 c.

Jim, whether I'm right on the above is not important, and I only liked to make clear that these things just are not in books. If they are, I'd like to know them (too), but chances get smaller since your question remained unanswered for quite a week. Please note that this by itself may say nothing, because -and again- there are not so many out there who made their skill of this stuff.

To get a feel of response-related topics -for sure not answering your questions- you may look at http://fox.wikis.com/wc.dll?Wiki~TuneFox~VFP where I put some thoughts on my experience and which is about native VFP-tables only; Though I urged to shoot at it, there too came no reaction whatsoever, probably not prooving that my thoughts are right, but that there are few people interested in this subject, or just knowing (enough) of it.

Cheers Jim.
Peter




>An ongoing thread about performance over a LAN and a suggestion to use ODBC prompts this message. I have also read what I can (VFP7 Help) about Web Services and viewed the DEVCON keynote in full and like what I see regarding Web Services.
>
>I was formulating a message specifically regarding Web Services when this ODBC observation came up.
>
>The Question:
>
>Where can I read/learn, for each of Web Services, ODBC (VFP) and OLEDB (VFP):
>
>a) Execution charactersitics like
>--- Where it actually runs
>--- Whether it uses Rushmore
>--- Within a VFP app., are it's buffers or caches separate or shared
>--- 'state' considerations
>--- Data format conversion requirements (like to/from XML)
>--- Other things that are relevant (single-use vs multi-use, MSMQ req'd.?, etc)
>
>b) Performance expectations like
>--- overhead per use (call)
>--- volume of data over the wire
>--- rules of thumb (for deployment adviseability) regarding call frequency, data volume, etc.
>
>I'm confident that I understand 'regular' VFP considerations, thought that I had a handle about ODBC and really like the concept of Web Services best but have NO sense about it at all.
>
>Thanks
>
>Jim Nelson