>>SCATTER NAME would be the fastest way to create such object
>>
>>>Why is it necessary to clone an object is a fair question.
>>>
>>>I am writing a time and attendace app. It seems that the tables required to store the data have a more or less predictable structure, but their detail and totalizing fields will vary greatly because different places have very different rules.
>>>
>>>One way to handle this variety is to create detail tables where each detail or total field with a non zero value gets a record, but I think this would produce an enormous number of disk accesses which I would like to avoid. Another way may be to create objects in a data driven way to hold detail and totals in nicely named properties, and them save the properties in a single memo field in XML form or as a data array. In order to save time in object creation I would like to create a master object and then clone it each time.
>>>
>>>The original question I have is how to best handle the situation with flexibility and speed. Any suggestion will be appreciated.
>>>
>>>TIA,
>>>
>>>Alex
>
>That's a good possibility.
>
>Sergey, Naomi, Ed and Mike,
>
>What do you think of the concept of storing "field values" as properties of an object that is stored in a memo field?

I'm doing it in a few places where we have optional things, and code which will do it - and save the whole thing as xml (on disk or in a memo, or as just a text with attribute=value lines). The downside to this is that these aren't real fields, you throw away all the luxury of a relational database. OTOH, if you're storing xml, then I'd go with Sergey's suggestion to just build cursors, even if they may be single-record, and then cursortoxml() them into a memo. At least you get some structure there, and when you rebuild the cursor, you can do with it whatever you want.

One more thing about xml - it's wasteful. Just today I zipped two xml files and got compression of about 23:1. Once upon a time I thought dbf is a waste of space, as a very sparse table, with lots of empty fields and blanks in long character fields would zip 10:1. This is worse, and it means that the larger your xml, the bigger buffer will be needed to retrieve it, and the longer it will take to milk the data out of it. I guess it's great for storing irregular sets of attributes with values, as long as it's nothing big.

It's taking me more and more words to say YMMV these days, eh? :)