Simple Employee tree

[Ender]

I came up with this as a possible structure for the Supervisor-Supervisee part of an Employee database. I wanted to account for the situation where any of an employee's line supervisors (up the organizational tree) could be seen from the current employee. This allows you to create security rules based on all of an employee's line supervisors, rather than just the immediate supervisor.

See attachment.

EmployeeTree.fp7.zip

[Lee Smith]

Hi Ender,

Thanks for sharing.

Just a note to interested parties, the file is in Version 7.

Lee

[Ender]

Sorry Lee, I missed setting that.

Unfortunately, this is an FM7 auto-entry trick that won't work in v6.

[Whit Porter]

Very nice. Thanks for the effort. Note: I pasted your summary of the file on the first screen in the copy I saved for myself. Might be helpful for others.

Whit

[jmobley]

Thanks for posting this file. I think I can adapt this to suit my needs for a nested project/task tree. The idea being that any project/task could see up a tree to see its parents and down the tree to see its children.

Here's the challenge I have, though. Using a structure like this, how do you get a report that you can print that shows the tree? For instance, using your file I've tried to create a report that shows

Supervisor

Supervisor

Employees

But I keep getting tangled up in subsummaries and sorting order and it doesn't quite come out right.

I'd like to try to adapt your structure so that I could have series of "trees" that look kind of like this:

Project 1

Summary Task a

Sub Task

Summary Task b

Project 2

Summary Task -m

Sub Task

Summary Task- n

I already have a table strucure that writes the parent id onto each child and captures a "project root" for each task in a series (where the project root id is equal to the id of the top-most task in the series).

Everything works in browse mode, but for the life of me I can't seem to get any useful reports out of it.

Any ideas for reporting & subsummary settings for mult-level parent-child-child relationships where the tables are self joined?

Any help would be most appreciated.

[Ender]

I'm not sure how this fits in with your sub-summaries, but I've attached an updated sample that can display the result in a report that's formatted like a tree. Maybe you can adapt the idea to your needs.

EmployeeTree.fp7.zip

[jmobley]

I hope this isn't a dumb question....

The file you attached is "php" -- isn't that a web app extension?

Is there a zipped filemaker file that goes with this upload?

Thanks for your help,

Janet

[Ender]

Hmm, maybe the forum was acting up. It seems to be working now. The attachement is a .zip file.

[awcase3rd]

Ender,

jmobley may have tried to do "download target to disk" which would give you a file called download.php.

-Al

[Leader]

Here's the challenge I have, though. Using a structure like this, how do you get a report that you can print that shows the tree?

---snip---

Any ideas for reporting & subsummary settings for mult-level parent-child-child relationships where the tables are self joined?

I solved the problem back in FM4 using repeating fields for the relatives and repeating container fields for 'drawing' the lines.

The screen displayed four rows of people:

1. parents, natural and adoptive

2. siblings and person of focus (max 7)

3. spouses (max 5)

4. children (max 7)

In other words, if we were looking at Dick as the current record, row 2 would look like

Tom Dick Harry Jane Sally ----- -----

showing Dick and his brothers and sisters.

I then used the repeating container fields to place connecting lines from the parents, down through Dick, his current spouse, and branched out to the children.

I was able to make certain assumptions. For example, I knew that there could never be more than 2 natural and 2 adoptive parents. Also, I happened to know that no one had more than 7 children. Therefore, I didn't get too fancy trying to draw individual lines for the children, I just 'hard-wired' in 7 lines for them and filled in their names in birth order, left to right, although it would have been simple to add the logic to limit the connecting lines to the number of children.

The visual effect belied the simplicity of what was actually done.

I added in a couple of features. If I detected that other people were in the same DB, then I displayed a button by their name to so that you could jump there immediately. The button was also displayed (or not) in a global container field.

Also, I added (faked actually) pop-up windows that allowed a quick addition of spouse and sibling names.

The DB is proprietary, but I can upload a graphic of it if that would help.

[jmobley]

WOW!! Thanks. I just looked at the employee tree view and I think this is exactly what I need! Haven't had time to try it on my project/tasks database yet but I wanted to shout out a BIG THANK YOU for everyone's help.

I just started using this forum this past weekend and I've already learned so much. This is a very giving community. I really appreciate this!!

Once I get my projects db more sorted out, I'll post it. Perhaps it will help solve some other poor newbie's problem as you have helped me solve mine.

Janet

[Leader]

The trickiest part you'll face, Janet, is learning how to use repeating fields correctly. FM has traditionally a minimalist program when it came to scripting and calculations... Loops are a relatively new addition, believe it or not. FM7 added a function or two extra in support of repeats.

The best trick is to create a global numeric repeat field (call it i) to use as an index. Then, you populate each cell with 1, 2, 3, ... n, where n is the maximum number of repeats you have to deal with. In your scripts and other repeat field calculationspts, you can use i as an index. It may not be obvious, but trust me, this is a terrific tip.

[comment]

I am not sure gIndex is necessary in v.7 - when you have Get(CalculationRepetitionNumber).

[-Queue-]

You are correct, sir. Get(CalculationRepetionNumber) makes an index field obsolete, as well as a lookup to the index field and a constant or Cartesian relationship for the lookup for repeating fields that need to be stored.

[BobWeaver]

Using a structure like this, how do you get a report that you can print that shows the tree?

I posted an example a while back which creates a tree type chart from a multi-level related file. Here is the thread:

http://www.fmforums.com/threads/showflat...=true#Post56689

It is probably adaptable to Ender's example as well.

[Leader]

Uh oh. I had taken a quick glance that Ender was using FM6 (which still requires the index field) and didn't catch the conversion to FM7.

Truth be told, I haven't (yet) converted any old index fields under FM7, but don't tell anybody.

This discussion promted me to relook at the FM4 example I gave above, and it's motivated me to address an issue I originall hadn't, in which a man might have fathered, say, 5 children by 3 different wives. Right now the graphical layout displays the children branches as if they all descended from the present wife. Tch, tch.

Hmmm...

[Sipa]

Cool stuff... I guess i just got inspired by this sample. As i will be finishing this by the end of this year i will post a sample.

TK

Sipa