creating record via a portal

[harryk]

When things do not work, you look at it again, look at the manual again, set it up again from scratch, and some way or another. You overlooked something obvious, or it is a combination of other things. At last it will almost always work.

Exploring (at last) all about relationships I encounter something I can not solve, and give up trying to understand why it does NOT work. It's simple:

I have a master and a slave. In the master I have a portal showing data from the slave. I created a many-to-many relationship with as a matchfield a calculation number field #Key=1 on both sides. The field in the slave is set to indexed. #Key=::#Key. In the 'edit relationship' section I checked 'Allow creation of related records'.

Everything works, the portal (with scrollbar) shows all the records, I can also duplicate a slave-record in the portal.

What I want and what does NOT works is creating a new related record from the portal. To create a record I do exactly what the manual states (section 2.5, manual 5.0/5.5). I type data in the field in the LAST empty portal row and then press [TAB] or [ENTER]. Nope. 'The relationship is not valid and must be corrected'.

I wrote the same from scratch again in FM5.0 (the first was in 5.5) but same result.

What am I missing? All conditions seem to be met. Is it the match-field causing trouble?

Harryk

<<..he gazed at the screen as a monkey in a rusty wrist-watch ..>>

[LiveOak]

I think what is tripping you up is the calculated key in the slave file. The option to create a new related record assumes that the automated operation can write the master key into the slave key field. I'll bet if you change the slave key field to a number field, all will work. The calculated One <--> calculated One relationship is a little degenerate. It is mainly used for passing globals (although an invalid relationship also work and doesn't generate network traffic due to matching keys) and showing all records.

-bd

[harryk]

> whats tripping you up..

Trip me up Scotty..

You won the bet. It worked. Changing the right side of the matchfield to a number did the trick. Then you must remember to auto-enter the 1-value (or whatever you choose). On the left side I still use a calculation #1=1, which works fine.

The simple experimenting with simple examples makes a lot clear. Hope you all do not mind my newbie humbling and stumbling on 'go related'; I've a lot to catch up on that..but I'm not in the least ashamed of it.

I've come to some semi-important newbie conclusions though:

When you 'are' in the master file you can add records and put data in related files 1) in the related file itself or 2) via a portal.

1) you can perform a subscript in the slave from a script running in the master, in that subscript you can add new records, and fill in data. But you must all do it in the subscript, not halfway. The moment you go back to the main (master) script a SetField(::field) is not orientated on the new-made selected slave-record anymore.

You can go back to your master with the 'go to original layout' script step.

2) you can add records and add data in a related file via a portal. Then the 'new-record' script step is not to be used. Use <goto portalrow last> and use SetField(::field). The fields do not have to be actually in the portal.

Hope I'am correct on this all. Especially the 'master perspective' and staying there or at least going back to the master without additional back-relationships in the slave can be important for making smart binding solutions, I think. The less fixed filenames, the better.

Harryk

[LiveOak]

There really is no subscript step that forces a return to the calling script. What really does it is to have a step AFTER the Perform Script(external or not) in the calling script, even if it is just a Goto Field() or some other "non-action" step.

I think you will find that a setfield to a related field will create a new record (when not in a portal field) only when no related records currently exist. Otherwise, the SetField (relationship::field) will just set the field in the first matching related record.

[harryk]

There really is no subscript step that forces a return to the calling script. What really does it is to have a step AFTER the Perform Script(external or not) in the calling script,

Right you are, my suggestion was unclear about that.

Harryk