Is it me or they didn't fix the problem with multiple portal in FM 10?

I need 6 portals and in each one there is another one.

How can I fix this problem?

Thanx

Here's a printscreen

I don't know what "the problem with multiple portal" is, and the picture is not telling me much.

I suspect this is a duplicate post:

http://www.fmforums.com/forum/showtopic.php?tid/202842/

Actually, the subject of this post is different from the linked post.

The first post was for the underlying structure (Tables and relationships).

This post is about creating a layout with multiple portals.

Layout = Parent

Portal = Child

Portal_2 = Grand-child

In this problem, the first portal is okay, all the others show the values from the first portal...

Edited April 20, 200916 yr by Guest

There are no such things are nested portals (portals in portals).

However, you can create a calc that uses List (Child::ID) and then create a relationship from this calc field to the grandchild TO. This will allow you to have another portal displaying all the grandchild records; but again not within the child portal...

Hmmm... I don't get the thing with the list (child:id). Can you explain your method?

Actually, the subject of this post is different from the linked post.

Is it? Then why did you link from there to here?

Let's try a simple example...

3 Tables and their fields

Parent (pkParentID, cListChildID)

Child (pkChildID, fkParentID)

Grandchild (pkGrandchildID, fkChildID)

Calculation:

cListChildID = List ( Child::pkChildID )

On Parent Layout

Portal 1: based on pkParentID = fkParentID will show all related children.

Portal 2: based on cListChildID = fkChildID will display all related grandchild records to all related child record.

Does this help?

Using this method, is it possible to sort the grand-children under the right parent that will look like the printscreen in the first post?

Please answer comment's question about double posts.

Lee

Simple, the first thread was about the structure and relationships of the database. So I posted in the "Relationships" forum.

The second thread has more to do with portals and not directly linked with relationships (Well, at first thought).

Both threads could be read independently.

Using this method, is it possible to sort the grand-children under the right parent that will look like the printscreen in the first post?

Sorry I dont know what you mean by this. I dont have a clue what that image is supposed to do or represent. If you are looking at a parent record, each portal can represent the child and grandchild records for that parent.

I tried your method, but I can't make it work.

The only way I found was to start the second portal at the eighth record.

Can you check what's wrong?

I attached the file to this post

forumInspection.zip

Sorry I still dont have a clue on what you are trying to achieve. I went back through your other posts as well. Are you trying to build something like a checklist with values? Do you want up to 4 inspections with different checklists?

Please remember that we do not know your business needs.

Sorry. You're right, it's quite clear in my mind, but not in the threads.

In fact, it's a sort of checklist.

This layout will be use to verify the construction progress of a house.

When a person gets loan to build a new house, an inspector has to go on the construction site to check what has been done.

He has to enter a number which represents the progress for each feature. The number is a value from 0 to the maximum weight of this feature, since it's a weighting system.

E.g.

The foundation of a single story house has a weight of 20% of the house and when the inspector went on the site, the foundation was completed so he enters 20 in the value field.

The structure was started but was completed only at 50%. So he enters about the half of the weight of the structure.

The inspector can go on site as many time as necessary and until the house is completed at 100%.

Usually it takes 4 visits, but sometimes we have seen 6 or even 7 for huge houses.

So this is how house building inspection works.

Now another important part is the weighting system. The maximum weight of each feature is different for each kind of building that we call category.

By example, the foundation has a greater ratio on a single story house than on a 2 story house. And there are many categories, single-story, double-story, townhouses are only a few.

Now in the database structure, there are obvious and less obvious tables.

• 
  
• houses : The house that is visited.
  
• inspections : Inspections of a house.
  
• inspectionValues : The values that the inspector enters for an inspection.
  
• lutFeatures : Lookup table of the features. Actually there are only a few features, but it could eventually change in time.
  
• featuresWeight : The maximum weight of each feature, depending on the selected category.
  

So the main problem is more like making multiple portable work.

At first I thought that portal in portals was possible in FM, but it doesn't seems to. Someone wrote about a calculated relationship with a list, but I didn't get that logic.

Thanks!

Well I guess I would be that "someone". lol.

Anyway, I think that you are going about this the wrong way completely. You may have to rethink your user navigation design. Furthermore, Michael is correct that you should have searched for +survey.

Here are the tables that I think that you need:

Property - which has a field that captures the type of report template that it will need

Checklist - has the template type, inspection item, and maximum values

Inspection - The inspection information

InspectionValues - The entered values compared to the checklist

Here is a rough example. It uses one trigger to clear the global field if a record is changed.

Multiple_Inspections.zip

Thanks John,

Your file seems nice.

I know my user interface is not awesome, but the users need a quick way to check for previous value. I guess that an extra global field with repetition could do the job for temp values.

After reviewing your file, do you think it's possible to normalize the checklist table? Or it may complexify the structure too much?

Well I left adding an additional table out of it so that the example would be easier to follow and I didnt see housing type specific data. It cant be easily modified to incorporate another table if need be.