>>>>>Hi all!
>>>>>
>>>>>We are retrieving data from a VFP app. No problem for the standard DBF data but some of the data was saved in .MEM variables files. So easy to RESTORE FROM in VFP but we haven't found a way to convert them from C#. Variable names and variable types appear in clear in the .MEM file. Character type values are also readable but numeric and date values seem to be encoded. We haven't found a description of the structure of the .MEM file. Does any one have a solution?
>>>>
>>>>Do you have to do this on an ongoing basis? If not, just restore the file once in VFP and then save the data out to some better format.
>>>>
>>>>If you need to share data over time, is it possible to change the VFP app? MEM files are incredibly outdated.
>>>>
>>>>Tamar
>>>
>>>Thank you Tamar,
>>>
>>>Unfortunately, we will need to do it often (hundreds or thousands times) and can't change the VFP app. In the meantime, I found some info about the Clipper .MEM file format here: http://www.zelczak.com/clipp_en.htm
>>>
>>>It might me similar to the VFP one, right?
>>
>>Would an alternative approach be to create a new VFP app (COM server, perhaps) whose sole purpose is to read .MEMs and save them in a desired format for consumption by C#?
>>
>>hth
>
>Thanks Alex. This is an option we considered but, as our apps are in .NET Core and might one day run on different OSs, we try to avoid any COM or external libs.

Guessing you do not have sources for your the specific vfp app
(and the original dev is unwilling to save into alternate format)
create a simple vfp exe that will watch the target directory

eventbinding on  new mem file(s)
   _screen.comment = lcMemfile
   clear all
   set alternate to forceExt(_screen.comment, "Lst")
   restore from  (_screen.comment)
   set alternate on
   list memory like *  && filter out some system memory if not included in mem file
    set alternate off && read in other prg
  * rename / move / delete mem file
  * call other prg to work on  .lst
  * log
  *  rename / move / delete .lst file

probably some minor logging or similar stuff will be needed for guaranteeing
correct working in your infrastructure. Would be nice to give back the bare bones
(with just stubs / function calls for your infrastructure included)
to Thor project.

Hacking memfile from zero to finish might take a day or more,
especially if test code is added or a spec from other language is
discussed, defined, implemented, rearranged, patched and so on
;-))

HTH
thomas