conditional check boxes

[Shane Carruth]

I have been creating a sports card database. I think I've got all the bugs out of the main database and the feeder tables. Now I'm on to working on getting the finial reports/tables from an idea to a working filemaker table. So, this is what I have in mind. I want a table that at the top, I have Manufacture, Brand, Year, Card #, and Sport. This table would pull from the other tables to get info. Those areas are easy to configure, but I want to be able to see what cards I'm missing in a set and what I have for complete sets. As you see from the screenshot, it has check boxes by each card number. I was thinking of mirroring this, but I am having a hard time on thinking of how to set up the check boxes, how to make them fill in when there is a corresponding card # with the check box

[Fitch]

Should be fairly straightforward to do using portals.

[Shane Carruth]

Please educate me in the art of using portals in this method

[Fitch]

Let's say your first portal has 20 rows. Duplicate the portal and set the initial row to 21. Etc.

 

You could highlight missing cards with conditional formatting using a formula like:

IsEmpty( related::card )

[Shane Carruth]

That sounds awesome and an easy fix, but question that comes to mind. Do I need to make a table for each Manufacture, Brand, Year, and Sport, or will the portals find the corresponding cards per the given criteria.

[Shane Carruth]

Ok so finished creating the table I wanted, but when I used a portal I'm not getting the layout I want. I don't know if I'm doing something wrong or it is what it is. The layout that I desire is something like what I posted in the original example. The other thing, is that it doesn't appear to be conditional. I can't change one of the fields and then the card #s associated with that Manufacture/Brand do not switch with the new selection. Here is a screen shot of what I have now.

[comment]

See if this can get you started:

 

ViewerPortals.fp7

[Shane Carruth]

Nope I'm sorry Comment, that didn't help any. I still can't get the card numbers to change when I change something on the table

[comment]

11 hours ago, Shane Carruth said:

I still can't get the card numbers to change when I change something on the table

You need to explain this requirement in more detail. Originally, you said:

On Thu Nov 5 19:51:10, Shane Carruth said:

I want to be able to see what cards I'm missing in a set

For this to happen, you must keep track not only of the cards that you own, but of all the cards that comprise a set - whether owned or not. If the item is unique (i.e. if there is only one exemplar to be had in the entire universe), then - and only then - you can use a checkbox to mark the ownership of the item. If not, then you must either use a Quantity field to record the number of exemplars owned (as shown in my example), or use a related table to record each owned exemplar in detail.

[Shane Carruth]

The top fields that I have set up, Year, Manufacture, Brand, and Sport. Those are all variables that can change and so I would like the card number and quantity to reflect the changes. For example, 1987 Topps Topps Baseball, and I have cards in the database from card # 2-50 but there is a total of 650 cards in the set. I would the the check marks to fill in for the cards I have, but if I change the year for example, I may have different cards in that set and be missing some others so I would like the portal to reflect those changes. The only way that I can describe it is a conditional set up.

[Shane Carruth]

Ok so I was just playing around with the table, Manufacture appears to be the only thing that changes the card # and quantity in the portal. It is pulling all the information from manufacture, I want it to be specific to year and Manufacture, Brand, and Sport

[comment]

1 hour ago, Shane Carruth said:

For example, 1987 Topps Topps Baseball, and I have cards in the database from card # 2-50 but there is a total of 650 cards in the set. I would the the check marks to fill in for the cards I have, but if I change the year for example, I may have different cards in that set and be missing some others so I would like the portal to reflect those changes.

Sorry, I don't understand what you're saying here. If you change the year you are viewing, then the cards being viewed will also change accordingly. And since each card has its own Quantity field, the portal will "reflect those changes".

 

14 minutes ago, Shane Carruth said:

Ok so I was just playing around with the table, Manufacture appears to be the only thing that changes the card # and quantity in the portal. It is pulling all the information from manufacture, I want it to be specific to year and Manufacture, Brand, and Sport

In my demo file, there are three attributes an item can have - color, size and shape - and all three work the same way. And there's no reason why there couldn't be four of five or any other number of them.

Edited November 8, 2015 by comment

[Shane Carruth]

At this point, I'm not sure what I have done or not done to make this only work partially. I took a screen shot of what I'm talking about, I kept everything the same except the year. It should have changed the information in the portal but did not. The only thing I can think of is relationship so I have attached a copy of that as well.

[Shane Carruth]

anyone help me out on this one?

[LaRetta]

Hi Shane,

Your graph looks nothing like Comment's graph.  

[Shane Carruth]

Honestly, I couldn't use check marks for year, manufacture, and brand. For Manufacture has 170 records, and Brand has 670 records. I have those two setup as conditional look ups.

[Fitch]

Checkmarks aren't the issue. That was just for demo purposes. The point of which was that you create one or more global fields, and you then create a relationship for the portal using the globals on one side, and your data table on the other.

You might also show ALL records in the portal, or use only one or two of the globals for the relationship, and use the other globals to filter the portal. Be aware that a filtered portal will be slower than a relationship, but usually not that noticeably until you get into many thousands of records.

So: you may want to create a separate "dashboard" table; create your global fields there; set up your relationship from the dashboard to the cards table; base your layout on the dashboard table; etc.