Hi Cetin,

Tried it little bit more last night, and here is what I found.
It is actually 'scatter name' that is causing all that delays.
Also promising measurements I reported were actually wrong!
I noticed that on consecutive run, despite showing (ww) that function completed - vfp was still showing glasshour for few moments.
So I let function run 2 and 3 times consecutively. After that truth came up.
It would actually take arround 2 seconds per call, which is twice slower then aproach with array for memo and additional scan/replace/endscan.
(Machine: P2-400mhz 200MB ram [ Volcano! :) ] table: 2644 records)

So unfortunately, there is no much more space for improving this concept.
Anyways final result of 1 sec for 2600&1memo records on mentioned 'volcano' machine is not all that bad. That is in fact biggest table I ever transfered
session 2 session. Typically these are some smaller resultsets.

Also any way you turn it, whole thing is memory consuming, so only update
for faq I posted, will be actually - warning to release carrier object
as soon it has been consumed.

And yes, there is always cursor2freetable option available for bigger
tables...




>It might be. There are some little 'cheating' in my real world app really (hard to explain-basically I don't send back whole cursors back but row identifiers).
>Another thing I do when I need to 'pass' cursors is to instead use temporary dbc and temporary table/views (I won't go into debate part in .Net it's easier or not:).
>Cetin
>
>
>>Hi Cetin,
>>I was playing little bit with your code and found something strange happening ...
>>
>>Very first run of your code takes 9 seconds to execute ?!
>>Next consecutive run 0.410 sec.
>>
>>At first (when replied earlier today) I tought sql statement run on non indexed table (customers) was causing that delay but then I commented sql statement out of the picture, and let your function run on native table. The same happened ; 9-10 seconds. Second run 0.4 sec.
>>
>>Then I tried also within my object (with tmp cursor again) . Again the same!
>>9 second first run and again consecutive run 0.41 seconds.
>>
>>Will play little bit more tonight to see if this can be somehow avoided.
>>
>>
>>
>>>Hi Srdjan,
>>>About your FAQ entry. I didn't check it extensively but still sounded you're doing it longer than what it might be, hope this contributes for some improvement (up to 65000 records):
>>
>>>
>>>

>>>select * from customer into cursor crsCustomer
>>>oCustomer = Cursor2Obj('crsCustomer')
>>>? oCustomer.aRecords[5].Company
>>>
>>>Procedure Cursor2Obj(m.tcAlias)
>>>select (m.tcAlias)
>>>oCarrier = createobject('custom')
>>>oCarrier.Addproperty('nRecords',reccount())
>>>if oCarrier.nRecords > 0
>>> oCarrier.Addproperty('aRecords['+trans(reccount())+']')
>>> scan
>>>   scatter name oCarrier.aRecords[recno()] memo
>>> endscan
>>>endif
>>>return oCarrier
>>>

I didn't include structure inclusion, error checking, restoring alias etc but I think this is more feasible (with multiple tables my real world production timings are under a second - never timed really, because the response was instant).
>>>Cetin