Is there a limit for number of portals in one database ?

[R2D2]

Hi !

I'm editing an old FM database. I have done this originally with FM6 (or FM7). I had to add more "boxes" to the layout. You can see the window in this link:

Each of the 20 boxes are portals showing data according the Call Sign on blue box. The setup for each is identical. I have just made the relations according the box number. You can see the layout here:

For some reason some of the portals doesn't work. I have checked and again rechecked the relations and they are ok. Box number 14 doesn't show any information. The fields inside the portal 14 are brought to the front in layout.

So is there a limit how many portals can be used on one layout ? Or what am I doing wrong (this time). I could show you the relations diagram, but it is so messy that I'm embarrassed. (I've made this originally on 2005...)

Thanks in advance !

//R2D2

[bcooney]

There is no limit to portals.

Your screen shots don't tell us anything about the relationships. Are the portals all the same relationship and you are simply showing a different initial row? Do the fields inside the portal match the portal's TO?

[R2D2]

There is no limit to portals.

Your screen shots don't tell us anything about the relationships. Are the portals all the same relationship and you are simply showing a different initial row? Do the fields inside the portal match the portal's TO?

Hi !

As I told, I'm quite embarrassed about the structure of my database. But anyway... Here you see it:

Every "box" has it's own relationship according the CS. I've checked that the those relations are correct. I have tried to copy paste those portals and changed the fields according the relation. But still it doesn't work. Could there be a bug in the FM software ?

[bcooney]

No, it's not a bug. Please...

Um, your screen shot still doesn't tell me anything (you only show one side of the relationship).

Let's take apart one of the portals. How are you doing this? What is the match field, and what data do you have in the parent that is related to the child?

Apparently, you don't want to post a clone. Then, post a demo recreating what you're doing (just two "boxes").

[R2D2]

No, it's not a bug. Please...

Um, your screen shot still doesn't tell me anything (you only show one side of the relationship).

Let's take apart one of the portals. How are you doing this? What is the match field, and what data do you have in the parent that is related to the child?

Apparently, you don't want to post a clone. Then, post a demo recreating what you're doing (just two "boxes").

Ummm... Here are the files. There is two files. Start the file called "OPS_center". When I first made this database there was not possible to add both files as different tables. As you can see, most of the "boxes" works perfectly, but there is problems with box 14 and 17.

Sorry for messy programming...

//R2D2

OPS.zip

[bruceR]

You have two Logfile tables. One is in the OPS Center file and has zero records; one is in the external file. Table occurrence Logfile14 points to the empty internal table.

Also you have a LOT of duplication of effort that can be avoided by using script parameters.

[R2D2]

You have two Logfile tables. One is in the OPS Center file and has zero records; one is in the external file. Table occurrence Logfile14 points to the empty internal table.

Also you have a LOT of duplication of effort that can be avoided by using script parameters.

Oh yes ! That is true. I had an idea to combine those two files to one file with 2 tables, but I didn't have time to finish that. Now that is corrected, but that box 14 still doesn't work.

And you are correct ! There is a lot of duplication, but when I started to work this there was no Script Parameters (or then I didn't know how to use them). I have plans to renew whole thing, but right now there is not enough time to do that. :unsure:

[bruceR]

Oh yes ! That is true. I had an idea to combine those two files to one file with 2 tables, but I didn't have time to finish that. Now that is corrected, but that box 14 still doesn't work.

And you are correct ! There is a lot of duplication, but when I started to work this there was no Script Parameters (or then I didn't know how to use them). I have plans to renew whole thing, but right now there is not enough time to do that.

Now WHAT EXACTLY is corrected?

Box 14 works fine if the relationship is corrected.

[R2D2]

Now WHAT EXACTLY is corrected?

Box 14 works fine if the relationship is corrected.

Uh oh... I corrected that relationship, and now box 14 works. Still box 17 isn't working among a few boxes. It seems to be very difficult to correct relationships in FM. At least for me... :B

[bruceR]

Uh oh... I corrected that relationship, and now box 14 works. Still box 17 isn't working among a few boxes. It seems to be very difficult to correct relationships in FM. At least for me...

Box 17 works correctly with no changes in the sample file you provided.

It is true that it does not display previous values; but that is the correct result.

The oldest previous values are empty and you have chosen a sort order for that relationship (and a few others) to display oldest first (sort ascending) whereas many of the other relationships sort descending.

[comment]

It seems to be very difficult to correct relationships in FM. At least for me...

Perhaps your time would be better spent rewriting the thing from scratch - and normalizing it properly.

[bruceR]

It seems to be very difficult to correct relationships in FM. At least for me...

As mentioned by Comment, that is partly because you are doing things the hard way, with an enormous list of relationships where just a few would do.

Normalization would also enormously simplify the scripting. Though script simplification could be accomplished with use of script parameters. You do not need 30 instances of a similar script.