Hi Aleksey

I am not worried about the speed of inserting records because it is minimal compared to getting the RecordSet. I only did it so I could force the retrieval of the entire table.

I will investigate early binding as I do not know much about that. Are you suggesting that I do something like CreateObjectEX("ADODB.RecordSet"...)?

You mentioned UNICODE conversions. The data the ADS Server is sending is taken from a standard VFP table on the server so would unicode be involved in such a case?

Thanks,
Simon White


>Hi Simon,
>
>>So I am wondering why VFP cannot process the records as quickly as the MSDatGrd.ocx.
>>
>
>There are several reasons:
>- MSDatGrd.ocx is compiled into native code, whereas VFP program is compiled into special byte code, which is interpreted by VFP at run time.
>- By default, when you call a COM object in VFP, it uses late binding (IDispatch), I would expect MSDatGrd.ocx to use early binding. You can use early binding in VFP too, see documentation for CREATEOBJECTEX() and GETINTERFACE() functions.
>- It is likely that MSDatGrd.ocx internally operate on Unicode data, VFP doesn't. This means that, every time a string is passed to/from a COM object, VFP has to translate it to/from Unicode. So, if you are passing a lot of strings, VFP has to do a lot of conversions and MSDatGrd.ocx doesn't.
>- You are executing SQL-INSERT command for each record, VFP has to interpret and execute this command. I am pretty sure MSDatGrd.ocx doesn't do that. It is probably using some kind of cache for data, but I don't know data for how many records it keeps cached, may be it doesn't even retrieve data for some records when you quickly scroll to the bottom. Also, the cache is likely optimized for specific MSDatGrd needs, whereas VFP cursor is more optimized to work with big amount of disk data rather than with small amount of in-memory data.
>
>Aleksey.