Maybe we should ask Ken to put the cache feature in VFP 10! It seems like your VFP service has a bunch of intermediate objects - anyway to optimize it and reduce the number of intermediaries. Perhaps the VFP performance would be a bit better (it don't seem that bad for a do-it-all guy like VFP!) if the intermediaries were reduced - and/or XML was used as the data container!

Thanks for the test!

>Hi Terry
>
>We have a VFP6 app written which is distributed amongst 7 different local servers around the County. At the moment we are writing an MDA Framework in C#.Net that is proving to be very powerful - I'll just mention this for the record, a full-blown MDA is not possible in VFP, not any version.
>
>Anyway, the customers came up with a requirement, they wanted to, from any workstation be able to query all of their clients in the entire county, as you can imagine this involves querying all 7 of those offices, compile the results and return a list of all found clients, so basically, a simple search.
>
>Seeing as we were working on this framework in C# we opted to use this as it was in workable form. This app isn't much to look at, I'm not here to compare GUI's as it runtime generates them - The app was a success, and, to my surprise, performance was good.
>
>Your post has prompted me to see just how good the performance is, I wrote this VFP PRG in version 8 that searches these 7 local servers (as the C# app does):
>
>

>LOCAL laOffice(1)
>
>lnSecs = SECONDS()
>
>USE Z:\Useful\Offices
>
>SELECT *;
>  FROM Offices;
> ORDER BY 1;
>  INTO ARRAY laOffice
>
>USE IN Offices
>
>CREATE CURSOR Results(Cl_Ref C(8))
>
>FOR o = 1 TO ALEN(laOffice, 1)
>	WAIT WINDOW laOffice(o, 1) NOWAIT
>   laOffice(o, 2) = ALLTRIM(laOffice(o, 2))
>   USE (laOffice(o, 2) + "client") IN 0
>   USE (laOffice(o, 2) + "property") IN 0
>   USE (laOffice(o, 2) + "foxguids") IN 0
>
>   SELECT DISTINCT Guid, Cl_Ref, *;
>     FROM Client;
>     LEFT JOIN Property ON Client.Pr_Code = Property.Pr_Code;
>     LEFT JOIN FoxGuids ON FoxGuids.Table = 'Client' AND FoxGuids.PKey = Client.Cl_Ref;
>     ORDER BY Cl_Sname, Cl_Fname, Cl_Dob;
>     WHERE Cl_Sname = "LAWRENCE";
>      INTO CURSOR temp
>
>   SELECT temp
>   SCAN
>      SCATTER MEMVAR
>      INSERT INTO Results FROM MEMVAR
>   ENDSCAN
>
>   USE IN Client
>   USE IN Property
>   USE IN FoxGuids
>ENDFOR
>
>?RECCOUNT("Temp")
>
>?SECONDS() - lnSecs
>

>
>Now, this little prg is light, simple & fast, it doesn't actually do anything but search, the results were 22 seconds.
>
>Now, the C# framework app we are using not only does the search, it also brings up a nice looking list of the clients, it has it's own cache infrastructure, it uses Business Objects to present the data, it is full-blown OO and guess what - it's querying Fox data, the result of the search in out framework was 17 seconds.
>
>I don't need to spell it out for you, the little fox prg is querying its own native tables, it doesn't do anything with the data apart from list all the primary keys. The C# app however, presents a search form, queries the data, turns the data into Business Objects, places them into the local cache, and then presents a list of found clients to the user.
>
>I can't actually believe this myself, a Fox app, querying its own data is slower than a C#.Net querying fox data - whoa!!!
>
>BTW, I just ran the C# app again because I couldn't believe it, guess what? 14 seconds.
>
>I haven't got time to write apps for the fun of it, here is a real life example/comparison, it's out there, it's working and it's overperforming.
>
>Kev