Hi Iain, What I've done in the past is to create a svc consisting of a non-db entity - two fields, seqno and a variable length text field. Seqno = save by user (curocc from creocc -1) variable length field = old occurence value three operations - add / get / delete You could use putlistitems/occ, xmlsave or the new struct's and store to the svc. When you need to, either add, get previous (or specific version) or delete.... Of course, there's the option to create a valuelist with a seqno and simply navigate up/down the valuelist - somehow I think that's more work on Uniface's behalf than a svc with a dummy entity - I might be wrong but large amounts of text in a valuelist - I'm not comfortable with that... Regards, Knut

It's the ease of getting a complex data structure packed up into one unit which draws me to structs. Valuelists and putlistocc are a pain to maintain if there are a reasonable number of entities (say 10) nested in complex relationships. XML is a pain to maintain if the fields in the component are changing, as maintaining a mapped DTD for the component is bloody hard work. Structs look like the way to go, but you can't store them in occurrences to allow for the recursion, and I don't understand how you can create an index for the structure to allow easy retrieval. Also, there really isn't any sane way for any of these data stores to maintain state at a field level, meaning that all field validation has to be turned off whilst unpacking the data back into the component. Componenttostruct appears to suffer from the fact that it backs up empty entities, and structtocomponent then restores them with the key field marked as modified, meaning that they all then fail validation... all in all, it's a really hard job to just put a component's data in storage and fetch it back....

valuelists - yep, agree. xml - I personally use "load component structure" in the dtd editor - very fast and easy to remove extra fields painted that doesn't belong to the xml stream. BUT - I can see a use for the componenttostruct(/one) here.... ;================== componenttostruct/one v_struct1, "orders.sales" creocc "dummy", -1 occno.dummy = $curocc("dummy") structtoxml xml_struct.dummy, v_struct1 now you have the struct in XML - and can build a history.... As for the validate errors, once loading the data back to the entities, maybe using the trigger to either remocc or reset occmod would solve the problem? Knut

Except that uniface crashes on the structtoxml on the component I tried this on. Just plain crashes, kicks me out, gone, finished, no error messages just goodbye. So I have no chance of working out what it is that it doesn't like.

Hi Iain, Which version 9.5 patch level do you use? I'm aware of a problem with the structToXml statement when the struct contains an empty leave of type Boolean. This usually can happen when you convert the data of a component to a struct (using componentToStruct) and the component in question features a Boolean field that is empty. The mentioned occurs problem when using the patch E113 (or higher) - in lower patch levels the problem did not occur since all data in a struct is of type String. And we currently plan to resolve this issue in the patch E118 (scheduled for July 19). Should the above issue be different from what you are experiencing then we are dealing with a new problem here. In any case, please open a support call for this issue and we can have better look at this matter. Hope this helps. Thanks, Daniel

Hi, I meet such situation. To avoid this, convert the component to struct at the height level entity: componenttostruct v_struct, "ENTITY.MODEL" structtoxml v_xml, v_struct In the component, which recieved the struct: xmltostruct v_struct, v_xml structtocomponent v_struct->ENTITY.MODEL ; The model name is essential By this way, you can exchange complete tree of data model between components, but you need an entity at top of component.

diseli said Hi Iain, Which version 9.5 patch level do you use?

Patch 114. So right in the middle of this.... There will almost certainly be empty boolean values in the data stored. So that looks likely to be the issue. I still have the issue with recovering the data (almost regardless of how I store it) of it coming back requiring validation. I currently use getlistitems/occ/init when getting the data from valrep strings, and then release to reset the requirement to validate the key fields, but it results in reams of code which have to be maintained. I'm looking for a nice self managing method of storing the data and recovering it.