Hi kevin,

Just try to replace the scan, insert into with:

SELECT Results
APPEND FROM DBF("temp")

Also, in stead of first opening the files (which locks the table header for a brief time, causing a delay) just put it into the SQL Query directly (The SQL refreshes the buffers, which takes a delay) which probably is a bit faster.

Also, the result cursor is only containing one field, why then are you querying a larger number of fields with joins?

Also, How did you do the query of VFP data in .NET? Via ODBC ? Are both cases doing their data processing on the same machine (IOW is the data in both cases taken from the network)?

Not knowing of how much data is beeing involved, you can do this in one VFP statement by using a union all statement to add all results in one cursor in one SQL statement.

But more importantly, there is virtually no data munging involved here. It is just querying that data and add it to some list. This is not the type of data processing that is going to make a difference, esspecially if you're using a VFP ODBC driver to get the data in the first place.

It would be interesting to see what difference these adjustments would take.

Walter,



>

>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