Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About vwgtiturbo

  • Rank

Profile Information

  • Location
    Lincoln, CA

FileMaker Experience

  • Skill Level
  • FM Application
    14 Advanced

Platform Environment

  • OS Platform
  • OS Version
    Win7, Win10, and Mac El Capitan

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thank you for the resources, Lee! I will keep those references handy. Not being able to put together a properly sanitized variant of the DB I am using (for peer review), I ended up simply creating a different layout to use for searches. For whatever reason, going into Find mode (on my usual layout) and selecting a drop down menu field was resulting in "<no values defined>". This kind of made sense; in Browse mode, these menus are based on value lists based on related records, and in Find, the context of relation seems to be removed. On the new layout, I opted for text input fields (versus the drop down menus). This allows the input of values that I am looking for. Thanks for the attention!
  2. I'll attempt to put something together this weekend. The database will require quite a bit of sanitizing and loading with bogus data. Thanks!
  3. Hello all! I'm sure this will be a very basic inquiry for the gurus, but I can't seem to wrap my head around it... My old FM database was a simple flat file affair, and searching was pretty much a no brainer. After rebuilding it as a relational database, I'm noticing that my searches are... impossible. Many of my fields are based on value lists, that are in turn based on related records. When I enter Find mode, and I select a dropdown that is set up in this way, I am met with "No Values Defined". Now, it makes sense that no values are defined, as I am in Find mode and not IN a record that is related to the choices in the dropdown menu, but I suppose I am wondering how everyone else does this? Do we copy these fields, and have them linked to value lists that include ALL potential dropdown choices (versus related only), then hide the copies when not in Find mode, or am I overthinking this? As usual, thanks in advance!
  4. Thanks for the 360Works link! Over the course of time and subsequent revisions/fixes/additions, the cost of this software could pay for itself easily if it works out well! Thanks for that tip! I honestly had never heard of data separation (this is my first complex database; all others have been single-user flat-file type). I wish I would've thought of this before fielding the database to begin with, hahaha.
  5. Hello, The forum search is failing me, and Google is yielding old results, so I figured that I'd take a shot in the dark here... I built a fairly complex database a few months ago, and sent it to my counterparts at overseas locations to use until I can implement one last (time-consuming) section. I am working on applying fixes to existing formulas/layouts, and adding new scripts/layouts/tables to a "Master" DB file. But it occurred to me that applying all of these changes would be nearly impossible for the other DB files (as far as ensuring that ALL changes are implemented across the other files, etc.). Is there a guide outlining the process for merging a user's existing DB data with my new 'fixed/improved' copy? Even though I'm dealing with 100 tables, I have no problem emptying all of the tables and resetting auto-increment record serials if necessary. From what I can find, it looks to be a tedious process (which I really don't mind), but am wondering if it is even possible to do this, while keeping record numbers/data integrity in tact across the 'new' DB file and their existing 'old' copy. Even a tedious import of the other user's DB data would likely be much easier than attempting to recreate all of the fixes/new design points a second time into their DB. Thanks in advance for any push in the right direction. I just didn't want to blindly follow one source's recommendation, and end up neglecting some aspect that wrecks the DB information already compiled.
  6. Nevermind... Solved it. Strange implementation (to my novice brain), but it works. Assigning the chosen graduation to a global variable, then using the value of the variable in the child table calculation was the way to go. EDIT: After further examination, the global variable wasn't needed. The original code works... if the record is committed. I guess when I moved on to the next record, the previous record wasn't committed, so the calculation choked. Adding a script step to commit the record after inserting the chosen increment, then pressing on with data entry, allowed the next record to evaluate the previous record's value, and increment it properly. Derp. Sometimes it's the simple things...
  7. Hi there! I've been beating my head on the desk for about a week trying to figure out an issue with auto-incrementing values in a child table, dependent on a value in the parent table, and it is driving me absolutely insane. In a previous iteration of the DB, auto-increment was working fine, as the value to increment the field was hard coded (i.e. incrementing the value by 1 for each successive child table record created). However, through real-world use, it became apparent that this was not ideal, and that I needed to have the option of incrementing the value by 1 or by 2. So, I devised a field in the parent table for the user to select which increment should be used (1 or 2). Unfortunately, since this time, the auto-increment has never worked. I've been experimenting with various 'If' statements, 'Case' statements, etc., and have had zero luck. I have usually had good luck in solving my own issues by creating the simplified example to post here, but this time, all of my trial and error has yielded zilch. It seems like it should be really simple, but... I'd really love some insight into why my setup isn't working anymore. I created an example file (as I can't post the actual file used). The structure is really simple, but mimics the actual DB. Thanks, as always, for any insight or push in the right direction! Auto-increment Based on Parent Value.fmp12
  8. 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.
  9. 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).
  10. 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. 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...
  11. 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
  12. You are amazing, thank you tons for the sample! After reviewing this file thoroughly, I came to the conclusion that I was looking at this all wrong. I was trying to use the 'New Report' aspect of FM, and I think that the grouping options and such just confused me (I could never see the results that I had my mind's eye). It seems that working backwards (trying to use the report to filter the data, versus filtering the data then reporting on the end 'found set') complicated matters (especially with regard to the grouping options I was setting up). Nothing would sort as expected, etc. In any case, beyond straightening my thinking, I now know how to utilize global fields :-) I don't know why I've never gotten that to work correctly... All I need to do is figure out how to get the Increment worked into this (and sorting them), and figuring out print presentation, then all will be well. Your file gives me a great start! Thanks again for the help! I am SO ready to get this section of the DB done; I'm tired of looking at the same area and am ready for a change. Light at the end of the tunnel, so to speak... As a side note, the script step for going to the Sessions layout never would have crossed my mind; I couldn't wrap my brain around it ("I don't want to go to that layout! Oooohhh..."). Light bulb eventually went off, but I never would have thought of it. Thanks again!
  13. Using the same layout that I use for data entry to practice this (based on sessions, with the portal), the process works well (select equipment s/n from the pop-up normally used during equipment selection upon input, view the number of returned records, omit (total - 1) since all are entered chronologically). I never could get this to work with a report based on the Measurements table (from my reading, it seemed to me that reports should be based on the most child table, which, with my understanding, would be the Measurements table). So... I suppose I can duplicate this layout including the use of a portal (but cut out the superfluous elements not necessary when viewing/printing the information), then use a Summary field in the Sessions table to count the number of dates returned, and after the user selects the equipment to search for, omit (count - 1), or am I thinking of this entirely the wrong way?
  14. My apologies for such a late response. After reading the last reply, I decided to do a bit of reading so I wasn't a burden asking basic questions. Needless to say, I'm not sure if the design of my relationships/tables isn't conducive to what I'm trying to do, or if there is some basic principle that I am looking past (likely the latter). By reading this statement "You can find the latest measurement session, then do Go to Related Record[] to produce the report from the measurements table.", that would work in some cases, but I was hoping to go the other way. The method mentioned would show a list of dates to select from and Go to Related would show the resulting Equipment IDs and Measurements. What I'd like to do though is select the equipment first (as that is the most important aspect that we need to narrow the data by), then return all measurements under the LAST session date for that particular equipment. Going through the Report creation tool (an untold number of times), I'm not sure where I'm going wrong; maybe the terminology in creation doesn't suit my use case or I'm including too many grouping fields, (or not structuring the resulting layout properly), but I usually end up being able to successfully search a particular piece of equipment, but then ALL dates (and therefore, ALL measurements, even those out of date and no longer relevant). I experimented with setting a global field (the user selects the equipment serial number) for the Find operation, and never was able to make it work (not sure if that was even necessary, but I was trying anything). In all fairness, however, I've never had a global field/variable work, so that it obviously something I need to study and learn...
  15. Hmm... I think the part that is tripping me up is that a user would ideally search for the serial number first, but from what I've read on related searches, the report has to be based on the most 'child' table (which I assume, in my case, to be the table with all of the actual measurements listed). I think that the design of the tables themselves might not be helping me, but it seemed like the most logical (to avoid repeating data, space considerations, etc.), considering that the equipment serial number isn't located in the most child table. The increment is literally an 'increment'. So, when the measurements are done, date and equipment serial number are recorded, and the observer sets an adjustment (ranging from .5 to 2.5, in .05 increments) then there are 10 measurements recorded for each increment (e.g. set adjustment for .50, measurements 1 through 10; set .55, measurements 1 through 10; set adjustment to .60, measurements 1 through 10, etc.). Initially, everything was jammed into one table. So the date and equipment serial number were repeated hundreds of time, for one measurement 'session'. It just didn't seem right. Maybe I'm just not looking at this the right way...
  • Create New...

Important Information

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