Should I be concerned that Sesame may post values to an incorrect form when using the Formfieldvalue command to post data to a subform with the current record open in ADD mode and a different record opened using the same form, but in Search/update mode? (both Add and Updates modes open displaying the same form, but different records, simultaneously)

Is there a chance Sesame would post my data to the wrong form? Is there way to safeguard aginst this sort of thing?

I'm asking becuase I'm still having a problem with natural linked records disappearing and/or attaching themselves to incorrect parents.

Thanks,
Steve

Steve,

Even though your subform records are "Naturally" linked, that does not prevent you from including a "Key" element in them just like you would have if you were using "Relational" linking. This may help you to spot if there were any child records on the wrong parent.

Maybe you are already doing this, and that's how you're spotting them now. But, I thought I would just mention this, in case you didn't think of it yet.

Bob and Carl,

Yes, in addition to using Natural linking, I also have the forms tied together via Relational linking with matching key fields in the parent and child records. This 'backup' link is essential for correcting this issue I am having. 

The only way I have found to correct the issue is to export my data using the relational linking and then import them back into sesame using the natural linking.

We still prefer to use natural linking becuase relational linking is very slow when doing searches from the child records.

Thanks for the input.

Steve

How can they be tied using BOTH Natural AND Relational? 
Is that really possible? 

I include the fields to "relate" parent and children records, but stay with Natural linking structure for the speed.  I stopped using Relational structures once I was aware of the speed differences.

Bob_Hansen wrote on Nov 11^th, 2006 at 7:31pm:


You can have one parent natural link any record definition ("database") and as many as you want link relationally. It is possible because the natural link cause the parent to point to the first child, then each child points to the next child:

Parent's child ID: 12
   12: Child 1 --> Next: 17
   17: Child 2 --> Next: 32
   32: Child 3 --> Next: 91
   91: Child 4 --> Next: NULL

The example above shows a parent with four children. The last child's "next pointer" points at NULL, and ends the list.

With relational linking, the parent does not "point" at any children, it simply gathers those children that share the correct value in the key field by running through the list of all records that match the record type for its child. Because a relational parent does not concern itself with a child pointer, nor do relational children affect their "next pointers", both relational and natural linking can take place on forms at the same time.

But, it is a rarely needed capability that adds greatly to design complexity. Using this to check whether child records are in place, is likely to cause many more problems than it solves, especially in a highly automated application.

Quote:


That is a better idea for checking whether child records are landing where intended. It allows the user to reattach orphaned records easily. We have seen very little unintended orphaning lately. It seems to be reserved to a handful of users that are either running applications that were created before Sesame 1.0 (during Beta), or those that have been unlocked while running - or both.

As to finding the condition, yes. When leaving the record, count the children and place the count on the parent record. Then create a mass update that counts the children and compares the count to number held on the parent.

That would serve as a temporary bandaid. From your symptoms it sounds as though this application has a record pointer off in one or more of the children.

In Sesame 1.x.x, finding the records that have bad pointers is difficult for the end user. It usually caused by unlocking an active application and writing to it from a different memory image (running copy) of the same application. So the value appearing in the "bad" record appears perfectly legit becuase it came from a legit, though not current, copy of the same application. Imagine if you had two copies of MSWord running on different computers, both writing to the same file. Both "authors" would write perfect english, but because they are both writing to the same file, the document as a whole, wouldn't make sense.

To find the problem yourself, the best option would be a process of elimination. on a *copy* of your application, run a mass update that adds a fake subrecord to the subform in question and counts the before and after record counts and moves on to the next parent record. Then run a mass update that checks the same parents for the correct "after" counts. Then do the same with delete. Keep track of which parent records exhibit the problem. It is likely that it is not those parents that have the pointer off, but one of their children.

In Sesame 2.0, we have several import/export options including a XML format that closely matches the internal format. This can make finding and fixing such problems much much easier for end users. It has replaced our in house diagnostic tools, and was originally derived from them.

Mark and Erika,

Thanks for the suggestions. I'm trying Erikas suggestion now and I'll try Mark's when I have more time.

Thanks again for the help.

FYI - Ray has suggested I use more 'formcommit' commands to help avoid the issue in the future. Hopefully that will help.

Steve