Jump to content

Conditional Value List Issues (I know...)


vwgtiturbo

This topic is 2421 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Well... I spent about two weeks of trial and error getting my DB to provide conditional value lists as I wished, since I couldn't post the DB online. After using the DB for a week (mostly flawlessly), my conditional value lists didn't end up working. Being frustrated after beating my head against the wall for so long, I researched (more) about this ability, and have come to the conclusion that either 1) I have issues translating simple two table examples to my more complex example, 2) I'm missing something fundamental, 3) my structure isn't conducive to my goals, or 4) I have issue with creating the value lists from the proper sources (which is easy to do, considering the multiple table complexity).

As a result, I created a greatly simplified and sanitized version of the DB (only containing the sections in question) and would GREATLY appreciate a Filemaker veteran's insight into how I could do this. The relationship graph of the DB file has notes that explain the desired outcome. I am just at a loss for words really; I've cursed FM relentlessly lately, hahaha.

Thanks in advance for any push in the right direction. I'm not looking for someone to outright solve my issue, but would really appreciate something that puts my mind on the right track, as my logic obviously doesn't jibe with FM.

Thanks again!

Flight Equipment Measurements (Simplified).fmp12

 

EDIT: I will make a copy of the above example file to show how the parts are related as of now (not that the relationships are correct, but I was able to ALMOST get it to work...). In addition, I will add notes to the updated file to show how the value lists are put together. Maybe it is just a simple thing to correct (although I AM more interested in starting fresh, the CORRECT way, versus my trial and error...).

EDIT 2: Well... After creating the extended (as constructed in my DB) example file, I've found that everything works as it did during my testing. So... It appears that subsequent relationships that I created after this section (in order to view reports/other related data) have mucked with the relationships in this section. Now I have to try and figure out which relationship is causing the problem, and attempt to design it out, while keeping the functionality in the rest of the DB. Ugh...

Flight Equipment Measurements (Extended).fmp12

Edited by vwgtiturbo
Clarification, Extra Examples
Link to comment
Share on other sites

This is quite confusing. All I can say at this point is that if you define a relationship between Flight_Data and Measurement_Sessions then "the hope ... to only show fk_increment_id that are related to the chosen session" will become a reality - assuming you realize the full chain of relationships:

 Flight_Data >- Measurement_Sessions -< Measurements 

Just define the value list to use values from Measurements::fk_increment_id, show only related values starting from Measurement_Sessions. If you're using separate TOs for this part, then adjust the names accordingly.

---
P.S. It's best to start questions like this with an ERD, so that the readers can orient themselves as they try to follow the description.

 

 

Edited by comment
Link to comment
Share on other sites

It is VERY confusing. I guess I should've expected that, trying to combine two 'only vaguely related' areas in the DB. Seeing how it's put together, it certainly makes sense that it was a trial and error approach.

What is kills me is how everything works in these simplified examples, yet in the actual DB, doesn't work (well... it works 2/3, with the last third being necessary). I have no idea how I managed to kludge it together and it's extremely frustrating. In the beginning, certain design decisions made sense, (not wanting to repeat certain data hundreds of times, like the date and serial number, so those were split into the Sessions table), but now... yuck.

Maybe it's just my desire to select the equipment (then have the available sessions displayed), the select the desired session (then have the available increments displayed), then select the desired increment (which would display the actual measurements) that makes things so complicated. I wanted to be able to drill down, but... it's hell, hahaha.

Thanks for the insight. I'll likely try and integrate your suggestion and see if it simplified matters, tomorrow. I'm so burned out from looking at this.

27 minutes ago, comment said:

This is quite confusing. All I can say at this point is that if you define a relationship between Flight_Data and Measurement_Sessions then "the hope ... to only show fk_increment_id that are related to the chosen session" will become a reality - assuming you realize the full chain of relationships:

 Flight_Data >- Measurement_Sessions -< Measurements 

Just define the value list to use values from Measurements::fk_increment_id, show only related values starting from Measurement_Sessions. If you're using separate TOs for this part, then adjust the names accordingly.

---
P.S. It's best to start questions like this with an ERD, so that the readers can orient themselves as they try to follow the description.

 

 

As an aside, when you reference the ERD... are we talking about just a screenshot of the relationships, or an actual ERD (that opens in software and can be manipulated)? I've not used a piece of software to create an actual ERD, and am eager to learn...

Link to comment
Share on other sites

4 minutes ago, vwgtiturbo said:

when you reference the ERD... are we talking about just a screenshot of the relationships, or an actual ERD (that opens in software and can be manipulated)?

Neither. We are talking about a simple entity-relationship diagram, uncluttered by the restrictions of the relationship graph (e.g. using circular references, if necessary). It doesn't matter how you produce it - for all it matters, it could be a hand-drawing on a napkin.

 

11 minutes ago, vwgtiturbo said:

I have no idea how I managed to kludge it together and it's extremely frustrating. In the beginning, certain design decisions made sense, (not wanting to repeat certain data hundreds of times, like the date and serial number, so those were split into the Sessions table), but now... yuck.

That is exactly why DB design should start with an ERD. If you don't have an ERD in front of you - if not physically, then at least mentally - then it's very easy to become confused. 

 

  • Like 1
Link to comment
Share on other sites

13 minutes ago, comment said:

Neither. We are talking about a simple entity-relationship diagram, uncluttered by the restrictions of the relationship graph (e.g. using circular references, if necessary). It doesn't matter how you produce it - for all it matters, it could be a hand-drawing on a napkin.

 

That is exactly why DB design should start with an ERD. If you don't have an ERD in front of you - if not physically, then at least mentally - then it's very easy to become confused. 

 

Ah, well I do have a diagram I put together in Dia, but am not sure if it meets the technical definition of an ERD (it is, after all, only my first large DB).

Link to comment
Share on other sites

Well, I wiped the entire section and just started over. With all of the other stuff in the live DB, I didn't want to risk breaking it just to accommodate this function. In the end, it is now MUCH simpler, and using a portal into the measurements table (from flight data layout), and implementing filtering of the portal based on the session and increment, am now able to display the 5 related measurements based on the session and increments selected in the flight data table. Thanks for the assistance! I likely never would have been able to fix it in its old state; starting that section over really helped out.

Link to comment
Share on other sites

This topic is 2421 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.