Hi Sergio,

>>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.
>
>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 :(

Hmm - surprising is an understatement
- I would have run it via macroexpansion and as a single line as from the logic of your old code,

  lcRep = "Replace all in" + cAlias
  for i=1 to oTable.FieldsCount
    if oTable.arrstru(i,2) = 'M'
      j = j+1
      *-- Replace does not really need ","
      lcRep = m.lcRep + Space(1) + oTable.arrstru(i,1) + " With oTable.arrmemo[recno(), " + Str(j) + "]"
    endif
   Next
  &lcRep

(untested, just from the hip) not via execscript, but that should not matter,
unless looking for the variables "living" in the previous stack is substantially different...
But the few cases I worked with generated multi-line-prg's I used the compile option,
so this is new turf for me.

>
>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.

Please do, I have a table in mind to try it out with on the WE,
both dbf and fpt > 1GB, so some disk access should be forced.
My UT adress works for attachments.

regards

Thomas