Activate/Deactivate a person in a table

[Don_Macaroni]

Hi guys, I could use some help here...

I need to activate/deactivate certain persons in a table so they would either show up in the overview layout I designed, or not.

Right now I have a field name 'person | status' which is either 'Active / 1' or 'Not active / 0'. I could activate/deactivate a person and do a search (or have a script do a search), but that's not what I want. I want a separate layout where only active persons reside. If I use scripts to do specific searches users could bypass this giving false results...

Hope I explained correctly, any help appreciated.

[GC GYM]

Maybe you could include the search in the navigation script that takes you to that layout.

Otherwise try a self join relationship and a portal to view only the records you want to see.

[Chappy.Cole]

Your skill level says, "Expert", so I suspect that I am missing something as I ponder your issue...

Anyway, it sounds to me like your solution is:

1. Define 2 global variables: gActive, gInactive.

2. Establish their values to whatever you use for your field Active, i.e. you set them to 1 and 0 respectively.

3. Create 2 Table Occurrences of your People table:

3.1 Active_People

3.2 Inactive_People

4. Create 2 relationships to your original (or any other) People table occurrence using the gActive field from the Active_People table to connect to your Active field and the gInactive field from the Inactive_People table to also connect to your Active field.

5. Create 2 layouts:

5.1 Active People: In the 'Create a Layout/Report' screen select the Active_People table occurrence from the "Show Records From:" pop-up list.

5.2 InActive People: same process as above but select the Inactive_People table occurrence

If you do that, then the layouts will always, only show either Active or Inactive people.

This is a self-join relationship using a global variable as a pseudo-primary key. Using global variables in this fashion is a convenient way to allow the user to select subsets of records which meet a certain criteria.

For example, you could create just 1 global variable (perhaps gSelectedStatus), put it on a layout which you display to the user to allow the user to select which group of records they wish to examine. On the layout, the global variable field is defined to show a pop-menu with a value-list which is defined to show all the unique values in the selected field (in your case, Active). After the user selects a value, they would have to click a button on the layout which would be defined to "Go To Layout..."

In this scenario, since 1 global variable can be assigned to either "Active" or "Inactive", you only need 1 table occurrence and 1 relationship (instead of the 2 that I described above), to display whatever subset of records the user selected.

Hopefully all that is understandable, as opposed to confusing.

[comment]

  Quote

If you do that, then the layouts will always, only show either Active or Inactive people.

I'm afraid you are very much mistaken about that. A layout - any layout - has access to ALL records of the base table, regardless of the TO associated with the layout.

[David Jondreau]

One solution is to have a table of "Active" IDs. Whenever a person is marked "Active" a record is created in this table and when marked "Inactive" their record is deleted.

The table would simply contain, as a foreign key, the primary key of the Persons table, along with the "utility fields" (primary key, creation date, etc).

Relate a TO of that table to your Persons table and base your layout on this table and show only fields from the related table.

[Don_Macaroni]

Thanks for the extended response Chappy.Cole, and I indeed started to doubt my "Expert" level, I felt I needed to change it to 4-Year-Old-Beginner... ;-)

What you described is exactly what I did (2 global fields, 2 relationships and 2 layouts). But when I click "show all" it still shows all records (activated and not activated).

As a temp solution I did make a search script which solves it pretty much, but again when a user clicks 'show all' all would show up.

Still working on it though...

[Chappy.Cole]

'Comment' is quite right about my plan...The TO one selects when creating a layout merely establishes the base table the layout displays and the network of connected TO's that are related. It does not, however, use any relationship.

Essentially, this is a case of you wanting to have your cake and eat it too, i.e.

Cake) All records, active and inactive, exist in 1 table: People

Eat it) Layout shows only one type of record based on status without chance of user getting to other type of record.

As you know, you can temporarily subset the records via a 'Find' (which the user can alter with another Find or Show All, etc.), or via a portal which uses one of the relationships that I described. Using a portal, although very useful in some situations, changes a lot of behavior for the user, e.g. how to change records, how 'Find' works. etc. I suspect the portal solution would not satisfy your needs.

There are various things you could do to achieve your goals, but I think that none will satisfy all your needs, unless you take control away from the user. You would have to limit what features the user has access to (e.g. 'Show All Records'), and write a script, or several (to perform 'Find's and 'go to Layout's).

This is one of my chief complaints about FMP...To create a bulletproof (i.e. user-proof) solution, one has to do 10 times as much work as to simply provide the data solutions.

[LaRetta]

  Quote

This is one of my chief complaints about FMP...To create a bulletproof (i.e. user-proof) solution, one has to do 10 times as much work as to simply provide the data solutions.

This is true in any software development. But in FileMaker, it takes 10 times as much work whereas in Access or PHP or all other tools, it takes 50 times as much work. FM is STILL the best bang for the buck in regards to rapid development. :wink2:

[Lee Smith]

  Quote

This is one of my chief complaints about FMP...To create a bulletproof (i.e. user-proof) solution, one has to do 10 times as much work as to simply provide the data solutions.

Compared to what?

This statement makes no sense at all.

Lee

[Chappy.Cole]

I don't doubt that you are correct within the realm of tools like FMP or Access, i.e. software that is both an application for developers and for users.

However, in my experience with software development using programming languages this problem is non-existent. In that world, the developer uses the language and related tools to create the source code and then transforms the code, via compilation, into the software that is for the user. Since the developer starts at ground zero and builds to a pre-determined set of features there is no additional work to be done. I'm not saying that such development is easy, trivial or even less work than using FMP. I know that I am comparing apples to oranges, but I cannot help myself since I have experienced both worlds.

[LaRetta]

  Quote

To create a bulletproof (i.e. user-proof) solution, one has to do 10 times as much work as to simply provide the data solutions.

Again. THIS is what I took exception to and you admit it yourself ...

  Quote

I'm not saying that such development is easy, trivial or even less work than using FMP.

Then I guess I still don't see your point.

  Quote

I know that I am comparing apples to oranges, but I cannot help myself since I have experienced both worlds.

Do you think you are the only Developer here who has experienced both worlds? I would guess that over 50% of the Developers here have coded using many other languages just as you (and I) have. You really shouldn't compare FM until your self rating moves up a bit.

LaRetta

[mr_vodka]

If you upgrade to FM10, you can use even triggers to contrain your finds to display active or all per layout or by value in a global field.

[gmmac]

In advanced, you can use custom menus to have "show all" show certain records based on the current layout....of course, you have to alter the finds etc. The 10x extra work. Which I'm about to start right now. Good luck to ya!

[ghettocottage]

I was just working through a very similar issue and I liked DJ's idea best, so I played around and got it working.

My issue was that I was working on a huge table of People. In this table was mixed "Guides" and "Students" (I didn't set this up, sort of inherited it). I wanted a layout that showed only Guides, and a way to check a person as a Guide or uncheck them from the People layout, and have that make them show up (or not) on the Guides layout.

I created a new table called Guides that only contained an id_People field to make the relationship between Guides and People,and then a serial, mod date etc. I also added a "Guide?" text field.

Then, in the layout for People, I added the Guide? field as a check-box.

Next, I added a script trigger set to trigger at Modify, and wrote a script that checks to see if the field is unchecked...and if so then deletes the related record in Guides table.

Im sure there must be a simpler way to do this, but it totally works...marking the check box automatically creates a related record in my Guides table..Guides layout is based on Guides table and shows related info from the Persons table.

Un-checking the box runs the script (with a polite message of "Are you sure you want to do this?" then deletes the Guide record and removes the person from the Guides layout.

This might be late but I thought I would post for posterity.

Thanks DJ