>>>Hi Thomas,
>>>
>>>A bit of hjacking the thread, but I have somewhat similar requirement and was thiking today of a best way to implement. In one of my forms I'm using a cursor to record some information. My problem is how to pass this information to the calling form. One idea would be to make that form share DS of the original form, but I have reservations - I'd like to keep this form using private DS. Passing XML doesn't seem a good approach. Using SD approach (I didn't re-check it) also seems a bit complex.
>>>
>>>Your ideas of the best way of handling this?
>>
>>See recent thread message#1420389
>>
>
>So this is the SD approach ? Reminding of the obvious (use of /as a table) is seldom wrong, and I should have done it myself, as I have some round-robin-code, which places the next "tableUsedAsCursor" on the next physical disk not used by the tables in the select statement. Speeds up things a lot, when set size is large.<g>.
>
>On the transfer via Array: While the approach is easy, increasing data sizes will create a lag - a couple of thousand records won't matter either way, but in scenarios of dbf/ftp both well above 1.5GB and a nontrivial count of needed indexes the appoach may be problematic. Working from the assumption that the specific cursor/table does not need to be included in the data isolation of private datasessions I believe transfering the whole cursor in an object with its own datasession and perhaps offering lineinfo as a data object to be accessible via form is a faster way.
>
>On specifics of the code from cur2obj and obj2cur:
>It is reasonbly safe to assume that your code is the fastest possible implementation with .MemoCount=0 <g>. Working the memo fields in a specific array is the first idea that would not be reached first if I had coded it : why not use the fields in the array not filled with the data from the memo ? The array mambers are already used in the memory schema of vfp (but as they are filled with .f. they dont incur the further penalty of long strings) so why don't you re-use them by accessing them with the loop varable already needed for deciding on the field type ? While the memory savings (reccount * no. of memo array elements * struc size of vfp variants) might not be decisive, you *also* gain the ability to work of each row directly via acopy into a singular arrayline - either as base for screen fields or to use with scatter from array to create simple rowbuffer-alike capabilities. This flexibilty would count much for me, as it gives the developer more options.
>
>Tables dominated by memo fields might even be processed faster by scanning the table/looping the array and using scatter/gather memo combined with acopy only - but that should be measured, as the time will fluctuate with the number and length of memo fields. Unclear if a cutoffpoint for deciding on different "execution paths" per table can be established...
>
>But the loop for the memo fields in obj2Cur is IMHO a suboptimal implementation, as it forces a tablescan for each memo var.
>Why not code one replacement statement including all relevant memo fields into one line, replacing all memo fields with one statement and one table scan ? Currently I cannot envision a scenario where the multiscan-approach is faster.

Hi Thomas

I played with it little bit ...

I eliminated second array as per your tip and indeed gained about 5-7% in speed.
After that went on and consolidated all memo replacements into one big replace command.
Created multiline replace command for all memo fields folowed by clause 'ALL' and then excuted it with execscript() ,
but to my surprise - speed increase was - None. Seem as if it did not make any difference :(

Good news is that even with 10 memo fields, speed was still ok.
14,250 (out of 26,000) recs was transfered in 2.6 sec in my memory conditions.
With 3 memos the same table went in 1.6 secs and down to 1.2 - 1.3 with a single memo.

Will send you refactored code via email if you are interested.
See if you have any more optimisation hints.

Sergio



>
>my 0.02 EUR
>
>thomas