After many hours spent trying to post to a subform, I must suggest that there is a bug somewhere.

I am simply using a buttonon the parent form to copy data from an element on the parent form to an element on the subform.  USUALLY, the data copies to the subform, but it always puts it in the wrong elements!!!!! The programming is simple:

FormFieldValue("LineItems", "action", 1, action)
FormFieldValue("LineItems", "quality", 1, quality)
FormFieldValue("LineItems", "pattern", 1, pattern)

Just to be safe, I have deleted and re-created the LineItems database and all the elements use the same name for Label, Name, and "Bound to" field, just to save confusion. The names are all the same on the parent form, as well. ALso, all the fields are text fields on both parent and subform.

For what its worth, I also have a button that does the reverse and it works flawlessly!

Stock no = @formfieldvalue("lineitems", "stock no", 1)
quality = @formfieldvalue("lineitems", "quality", 1)
pattern = @formfieldvalue("lineitems", "pattern",1)

Please help before I throw my computer into the neighbors yard!

Steve

Mark,

It appears that Sesame is simply posting to whatever LE it "Sees" first in the child database. It is not looking for the specified LE.

If you reverse the 'position" of the LEs in the Cities Database,  then "123 gets posted to the cities column, and "Berlin"  tries to get posted to the Population column, but a 0 is returned instead (becuase its a number field?)

I also added a couple LE's to the top of the cities db and it just made things worse.

Please confirm this on your end.

I'm using 1.0.2 ver. This bug is easy to reproduce for me. I tested in Add mode in Preview and in "actual" Sesame.

Steve

Thanks for looking into this. It also seems that the rules for importing into subforms have changed as well. I cant import into the parent and child records at one time.

This may all be related to the bug I reported. It looks like exporting is not going to work either (from the subform).

If there are changes to the way we are to import into subforrms, please add this to the manual addendum.

Thanks,
Steve

Steve,

We just tried both an export and an import from an application that was showing your earlier bug, and had no troubles. Could you be more specific about what you are seeing?

Mark, any luck fixing the subform header bug? Do you know of a workaround? Should I spend some time re-arranging the  layout of LE's on the subform so I can post to the proper feilds?

Thanks,

Steve in Texas

YOU GUYS ROCK! VERY glad to hear 1.0.3 is coming out soon.

I'll just wait.

Thanks,
Steve in Texas

No, you would need to use @FormFieldValue and its ilk. There may be other, better workarounds. Have you tried creating a new .dsr from .db, then saving the .dsr as a new .db (use backups) to try to force the headers back in synch? You may try deleting the subform off of the parent form (do not delete the subform itself) and putting it back on the subform, again to try to force synch. Remember to use a backup copy of the files.

Also, I suspect that we are only days away from an update. So you may want to wait.

Thanks for the suggestions. Still no luck after playing around a bit. I guess I'll just have to wait.

by the way,

I had been using LE names with spaces, such as "Import from File" and had 0 problems (testing found no errors, and everything worked fine), then for no apparent reason, testing found problems with the names, and I had to rename the LEs to names without spaces for the problem to go away.

Weird. If this becomes more common, you may want to disallow the use of spaces in LE names.

Just FYI.
Steve