I think I see.

Mostly what I am doing is moving records from one version of a database to another (say, my version and my clients version.)

Not really "application" kinda programming, more just code to try to get it done.

But, it sounds like you would reccomend using scatter name, and then stepping thru the object collection and drop the fields that are undefined?

>>>>And, what if I am moving variables into fields and fields into variables... Its a lot more convienant to call the variable the same as the field.
>>>
>>>Really? It gives both you and VFP more of an opportunity to go wrong, especialy since varables and fields have very different scopes.
>>
>>But if they are the same name, I can use insert from memvar, or use afields to go thru the list of variables as well as the list of fields if I had previously done a scatter memvar blank.
>>
>
>My opinion - brain damage. If you insist on using this type of behavior, look at SCATTER/GATHER NAME
>
>>When you are moving data around, do you variables (according to the standards) and then hand assign the values to them?
>>
>
>No - I either rely on buffering or use record objects or arrays. It's very rare that I copy fields into variables on a record basis. There's no need with VFP's buffering, the SCATTER/GATHER NAME constructs, and the ability to programmatically parse fields and create new names from them. I don't have to resort to editing in memory variables.
>
>>I ran into trouble with sql anywhere. If I try to write a empty or null date field into a sql anywhere remote view from foxpro, I get a C5 error. So, it kinda cuts out being able to use insert from array or insert name commands... I would rather not have to go thru the 600 or so fields in the 30 or so tables by hand. Its a lot easier to just release those variables that are empty or null prior to doing insert from memvar.
>
>Again, I suspect that I don't have the same issues you do because I handle data differently. YMMV. If you have data format issues, you should have the issues handled in the data services layer of your application. And again, you don't have to go through things by hand - it's possible (even desirable) to have data format compliance managed through metadata describing conversion rules, or through the data service layer code that provides a clean, consistent virtualized interface between the backend and your application's mid-tier and UI layers. YMMV. If your philosophy of how the system should be layered and your interfaces are based on another approach, my methodology would differ from yours quite a bit.
>
>>
>>Is there a better way?
>
>I've not had to rely on memvar-based editing for a while now; buffering provides an easy way to edit without needing an explicit layer of protection, and not relying on memory variables for editing reduces the need for PUBLIC/PRIVATE variables; memory variables don't cross COM boundaries, and reqire extra effort and (IMO) poor coding practices to cross between layers of native VFP code.