>>>>>It's interesting that VFP has no support for programmatically IMPORT from CSV, when it is capable of import from more complex file formats.
>>>>
>>>>It has such comamnd. Create table with fields in same order as in csv file and use
>>>>
>>>>append from csvfile delimited
>>>>
>>>>or similar to import.
>>>
>>>I think you're missing the point of the thread. Mel does not know about the structure of the CSV file, or it can be a lot of things, so he cannot CREATE and APPEND.
>>
>>Such files often happen to have some irregularities: think spaces in field names for example. I find the approach to analyze/create via the wizard better: atfer first import I check save the table structure plus sometimes a small prg to clean specific issues. Next import goes easier ;-)
>
>Unless there are memos involved, of course ;-)
>
>Anyway, as I said in the my first reply to Mel, and although the code I posted already took notice of the space in field names, that was just the fundamentals of the process. Naming is a problem, of course, even more because there are two set of naming rules involved (VFP's and XML's). Nothing that can't be solved with a minimum of effort, though.

Speaking of Memos: the base utility class responsible for importing has the option to create an intermediate cursor where all text fields are memos, so that a check can be made that new import does not contain text fields needing more chars than was previously deemed necessary.

Esp. importing from gov data such field len sometimes were changed and gov programmers will offer such info in their internal dokumentation, available via mail as soon as anyone asks again after change ;-)