Distinctions in related pop-ups in portal

[Savas K]

I am trying to filter clients in a pop-up located in a portal drawing records from a people table that contains both clients and vendors. The desired results is to eventually have two portals, each dedicated to clients and vendors in my projects table.

I started with the clients portal that worked okay without the client/vendor distinction then tried to modify it so that the pop-up only showed clients. So far I have failed to create the distinction. I used in the Role join file a global constant with text result that says "client" and made the join to read: locate persons using the person key AND the global constant, the person's type field populated with either Client or Vendor as the case may be. Thus far, all records show up in the pop-up - it's not limited to just the clients.

Is there a way to accomplish this, or should I bail out of using one file for all the people and create separate tables for clients and vendors?

[UpNorth]

Don't give up. You should be able to do this with one file. First thing first. Make sure your global fields are set in your start up menu. So in your project table you will want two global fields, global_vendor and global_client. Then create a script that set's these fields as "vendor" and "Client" at start up. From there you should create your relationships based on these fields.

Now a question I have for you is what do you mean by "popup" Do you have a field setup up with a pop up list? and if so have you created a list that pulls fields from the relationships you have created?

Welcome to FMForums, its a great place to be apart of.

[Savas K]

Thanks for the fast response and assistance.

So the globals belongs in projects and not in the join file? I'll try that. The relationship worked before except for when trying to filter by type of person. For my global field, I made it a calculation with the text result of "Client", assuming each record would possess that value to work from. I hope that is okay contrasted with setting the field at startup.

By pop-up, I had it setup as a pop-up value list using field content for the values, displaying a combination of primary key and another field showing full name; sorted by last name. Each people record populates a portal, as each project has multiple persons playing various roles.

Doing this method was just to prove to myself that I could make it work. Though it will soon be cumbersome once people records grow, whereupon I'll switch to scripting to perform a find in the people table, by two criteria - person and type of person (vendor or client), capturing the key and setting the appropriate field to bring them into the respective portal in the projects table.

[Savas K]

Here is an example diagram - I hope it posts.

[Savas K]

I think I'm onto something. I did a self-join in the People table, using the Type (Client) as a global, created a layout for that join and now it displays only clients in it's associated portal. I'll go one better and do one to display only vendors and maybe these two self-related join instances will lead to the functionality stated earlier. Fingers crossed. :

[UpNorth]

Well, I'm not a 100% sure how you are creating the relationships but if it's working... then great. If you run into any issues with the vendor let me know. Otherwise, as far as the global field you still want to set them at start up as common practice.... kind of like a safety net.

[Savas K]

I crashed and burned afterward. Not me, the idea. :

There are fundamentals I need to bone up on.

For example, something cropped up that I'm not getting. The fact that a new table occurrence group that is not attached to my initial related files in the relationship view does not show up in the list of available relations in a given layout until I create a new layout dedicated to that table occurrence group. I subsequently put some fields on it then lose focus. It feels like I've created an island. I lose visualization of where to take things.

What I was trying to do is above my present capability. I might opt for paid assistance, learn from it and move on with this database.

Edited January 21, 2009 by Guest

[UpNorth]

I'm sorry to hear about your idea, but I'm glad your safe ;-) If you want me to take a look at your database I would be more then happy. It sounds like you have some good ideas and are somewhat on the right track but relationships can get a little confusing. There are many different ways to manage them, and you want to make sure you have some type of method in place before tackling a large project.

I'd hate to see you give up.

Let me know if I can help.

[Savas K]

What a wonderful offer. Thanks. I'll keep trying on my own until I'm ready to end it all. Then I'll email you before the mental health hotline. heh heh ... :

Here's what's cropped up in the interim.

I have been fundamentally unprepared with my pre-version 7 thinking. I have kept up with releases, but haven't created anything substantial since converting my pre-7 files to 7 and beyond. Which is why today I sought out and found a white paper written by Michael Harris (Cerné Systems) that I wasn't ready for when it was initially posted. (for some reason, I'm unable to attach the .pdf to this email. Maybe Safari trouble.)

Briefly, out of many concepts written: Function-specific layouts are attached to a TO or a TOG. And conceptually, a TO does not equal a table. I was unfortunately treating the diagram view like an ER diagram. And the initial relations were such that it was easy to create a degree of functionality. But before long, it went into the toilet. Now I see why I inadvertently created an island disconnected from other tables.

I started inspecting, dismantling and otherwise kind'a reverse engineering an example file from Soilant Consulting, called Job Time Tracker. Sure enough, I discovered layouts with a faux-tabbed interface, with areas outside the tabbed areas duplicated per purpose-driven layout. Each layout was dedicated to a particular TO, of which items in portals represented records from other TOs from the same TOG.

FM documentation I find sorely lacking in this area. I have not seen this type of material mentioned anywhere in it. Of course, FM has to give you default layouts and tables. But Soilant's example files demonstrated that they deleted all the default layouts and tables in diagram view, creating specific layouts, TOs and TOGs according to their pre-determined functionality.

Soooo... I'll be working more on specific functions first and approaching my new creation in a whole different way.

[UpNorth]

Sounds good. If you want some good reading, do a search for "White Paper For FM Novice" It's courtesy of Foundation Database Systems. I don't believe in EVERYTHING that they cover, but it does have alot of good points.

Take Care,

Lisa