Frontal Lobe of the Cerebrum Teaser

[faaslave]

I am almost done with this database, and I am trying to do something that doesn't seem possible. Of course, everytime I think that and put the question out here, someone seems to find an answer. So I guess it's worth a shot.

I have attached the file, and here is the best rundown I can give.

When on the FLM (Front Line Manager) layout, you will notice that I have a portal under the tab "Evals Due" that shows all the evals due for that FLM's employees.

I created an eval TO for each kind of eval to get these results. That part works great.

There are 4 other items I need to keep track of. They are Errors, POW's, ODP's, and SE's. You will notice that I have a layout for each one of these items.

When you create one of these for an employee, it will involve tasks, and followup items to be completed. They are created in portals.

What I would like to do, is back on the FLM layout, where you see the tab called "Followup", I would like to see any tasks or fllowup items that are not completed yet, showing me when they are due.

I have no idea how to get the info out of these portals and on this layout.

If it is possible, I would love some help.

If it's not, then I guess I need to know the reality soon.

Thanks Dave

SupTracking59.fp7.zip

[Søren Dyhr]

Your graph is not easy to digest, but when you flip thru the various tables, does it seem like they're almost identical, except for some minor attributional changes, this points in direction of a structure not well considered - where tables actually can be merged!

This at least confuses me a lot, couldn't you untangle your graph in TOG's say an Achor Bouy'ish manner or such. There is absolutely no need for tying all TO's together, the RG is not a ERD!

The use of constants is in my eyes another weak spot in the relational structure, not quite using to tunnelling aspects of values from more than a relation away.

--sd

[faaslave]

Your graph is not easy to digest, but when you flip thru the various tables, does it seem like they're almost identical, except for some minor attributional changes, this points in direction of a structure not well considered - where tables actually can be merged!

This at least confuses me a lot, couldn't you untangle your graph in TOG's say an Achor Bouy'ish manner or such. There is absolutely no need for tying all TO's together, the RG is not a ERD!

The use of constants is in my eyes another weak spot in the relational structure, not quite using to tunnelling aspects of values from more than a relation away.

--sd

Well, I assumed that whatever table I created were necessary when I made them. I make no claims that I am someone to take advise from in regards to Filemaker.

And I am really confused when you say that I didn't need to tie all the TO's together. Without them tied together, how do you make the relationship?

I am sure that there was a much better way of developing the structure.

What I am trying to do is pull all of the records from the Tasks, and Followup TO's. Then in a portal, list all of them that are not completed for a FLM(Supervisor). That's it.

And I have no idea what an Achor Bouy'ish manner is?

Remember, I am just a rookie.

Thanks Dave

[jteich]

Achor Bouy'ish manner is?

see http://www.kevinfrank.com/anchor-buoy.html

-jens

[faaslave]

Thanks, I just downloaded it.

Dave

[Søren Dyhr]

And I am really confused when you say that I didn't need to tie all the TO's together. Without them tied together, how do you make the relationship?

Dupe the TO's enough times and make each graph reflect what's going on in a certain layout, no more no less than required to "read" the funtionality.

To the second half of you question is it beneficial to examine this behaviour of GTRR's:

http://www.sumware.net/robfm/savingfoundsets.php

What I am trying to do is pull all of the records from the Tasks, and Followup TO's. Then in a portal, list all of them that are not completed for a FLM(Supervisor).

Can you see that it's exactly the same problem they debate in this thread???:

http://fmforums.com/forum/showtopic.php?tid/181499/post/226500/hl/fenton/

Some kind of merging of tables is required!

--sd

[faaslave]

Can you see that it's exactly the same problem they debate in this thread???:

http://fmforums.com/forum/showtopic.php?tid/181499/post/226500/hl/fenton/

Some kind of merging of tables is required!

--sd

In the beginning of the database, I tried to keep it all on one table. It just wasn't possible. They were very similar, but different enough, that I need them to be on separate tables to make it work correctly. At least that is what I came up with. I could very well be wrong.

So what you are saying is, if I don't figure out a way to rewrite those tables so they are one, I will not be able to accomplish what I am trying to do.

My only other choice is to make another table, and figure out how to grab all the records from those tables and combine them in the new table. Then with that table I can pull the data out and display it how I want.

Thanks Dave

[Søren Dyhr]

So what you are saying is, if I don't figure out a way to rewrite those tables so they are one, I will not be able to accomplish what I am trying to do.

No it's not quite what I mean ...the common stuff should be one table and the matters that differs should go to another (other) table(s).

This video might give you inspiration in the slicing and dicing the data by other principles:

http://previews.filemakermagazine.com/videos/513/DataTagging_full.mov

need them to be on separate tables to make it work correctly.

Could you explain this, or is it accomplsihed by trial and error??

--sd