Members

12

0 Neutral

• Rank
member

• Industry
Aviation
• Gender
Male

## FileMaker Experience

• Skill Level
Novice
• FM Application

## Platform Environment

• OS Platform
Mac
• OS Version
10.13.5 High Sierra

## FileMaker Partner

• Certification
Not Certified

## Recent Profile Visitors

591 profile views

1. ## Rounding UP to nearest whole 50 or 100

I knew I wasn’t seeing the woods for the trees! Many thanks comment, that’s working perfectly. Regards
2. ## Rounding UP to nearest whole 50 or 100

Greetings I have spent a fruitless couple of days searching, testing and generally getting frustrated... I’m relatively certain my problem is a simple one, however: I am trying to calculate fuel required for a trip. It’s a simple Time/Speed/Distance calculation. The basic mathematics is in place and calculating accurately, so so-far, so-good. BUT, what I need the result to display as, is a whole number, Rounded UP to the nearest 50/100. So for example, if my TSD calculation returns a result of let’s say 716, I would want the result to display 750. Similarly if the calculation result is 751, I would require 800 to be displayed (an extreme example). This information is provided only as background detail for understanding: The reason for this is pretty much as old as aviation. We suffer from a fools-load of unit conversions, from airframe to airframe. For the airframes I have particularly in mind, the fuel on-board is displayed to us in lb’s. We order our fuel uplifts in litres. In very rough terms, with the error going in favour of a little more fuel on board than absolutely required, 60 litres JetA ordered gives us 100 lb uplift. So, if I have 450lb remaining and require 700lb for the next leg, I need an additional 250lb, for which I would request an uplift of 150 litres. Why I need to round to the nearest 50/100? Aircraft fuel gauges are not deathly accurate, particularly sitting on the ground. There’s always a little “fudge-factor” between what your gauges tell you and what’s actually onboard, mainly due to the attitude of the aircraft on the ground and it’s empty/loaded Centre of Gravity position during offloading/reloading operations. The gauges are best accurate in level, cruise flight. So, if you’re still with me, I want to round UP to the next 50/100 to add a little extra fuel to cover the “fudge factor” and give a little “Mum & the kids” fuel. very grateful for any advice
3. ## Change Log

@bcooney: many thanks! The google search has definitely thrown-up some interesting possibilities! I’ll look at each and see how best to implement. Why? My database stores around 450-odd different airstrips for which there has previously been no or very little data available for, as well as another 800-odd route and approach waypoints. The airstrip records each comprise roughly 90 unique data-points, the waypoints a lot simpler at under 10 data-points. I currently publish the data as PDF documents both electronically and as hard copy. The electronic document I further process with internal document links, which is currently running to around 900 links, every time I update the document. That’s a laborious manual process. The ability to print only (both electronic and hard copy documents) that have data-point changes since the last release, will simplify updating both documents massively. Additionally, from the audit data, I should be able to release a Change-log document, detailing what changes have been made where, allowing pilots to easily see which documents they may need to review fully and carefully, with respect to their daily operational needs. @Josh Ormond again thanks! I’ll be looking at UltraLog also. Email I’m not too worried about -and as always, I have some learning to do w Scripting as much as w FMP generally 🤪 many thanks for the suggestions guys RS
4. ## Change Log

Greetings I wonder if anyone knows of a method for FMP to monitor the fields and records in my database for changes, flag and report the changes on a semi-regular basis? if I can achieve a report, it would massively simplify my update process, for hard-copy and PDF distributed documents. TIA for any suggestions! RS

6. ## TIME entry format

Pleased to be able to advise, it turns out to be easier/simpler than I thought! I have modified all my existing TIME fields to be an Auto-entered, Calculated value, with the calculation above referencing back to the same field. So, if the field I'm working on is formatted as a Time field, and I have called it Time1, for example, my calculation is: Let ( t = GetAsText ( time1 ) ; Time ( Div ( t ; 100 ) ; Mod ( t ; 100 ) ; 0 ) ) I have unchecked the "Do not replace existing value (if any)" box. It's working exactly as I'd hoped, with everything working as it should.
7. ## TIME entry format

...and it works! Now all I have to do is work it into my database without upsetting all the existing calculations! The calculation: Let ( t = GetAsText ( YourTable::Timefield ) ; Time ( Div ( t ; 100 ) ; Mod ( t ; 100 ) ; 0 ) ) I created a calculated field, as above, selected Calculated result as: TIME, 1 repetition, and "do not evaluate if all referenced fields are empty" selected. Data entry takes place as 0125 in a TEXT field, and reports where I want it as 01:25. I'll need to do a little shuffling for aesthetics sake, but that's a relatively minor thing now. I said earlier: Having tested your scenarios as outlined, I find I was in error. 205 enters as 02:05. 25 as 00:25 and 5 as 00:05. Many thanks for the suggestion and advice!
8. ## TIME entry format

hmmmm ok, I'll go looking for it again! Thanks... likely my assumption it was a script-step that bought me undone. 205 would still enter as 02:05... the fields are all set for leading zeroes. 25? Don't know. I'll try it and see. Just 5? as I understand the data-entry rules for FMP, that would enter as 05:00. My understanding is that single-digit entries are assumed to be hours. You might be obscuring the woods with trees there a little... my database is designed for and will be used by aviation professionals, all of whom are pretty au fait with 24hr time-entry systems. I'm merely trying to nip a potential problem in the bud whilst saving a few key-strokes, in what can at times be a fairly onerous task 😉 Many thanks for the response -I'm off back into it to have a go!
9. ## TIME entry format

Greetings I'm running FMP14 on a Mac. I have several time fields, all of which are configured to UTC time in 24hr format and are working pretty much as expected. Several calculation fields are run off those fields. My issue is, during data-entry, not everyone is as consistent in their notation as perhaps would be ideal... we all know how FMP loves consistency! To resolve difficulties there, and remove the need to enter ":" between HH & mm, (as in 23:45 =5 keystrokes, and a Shift-key), I'd like my dbase users to be able to enter their times as simply 2345 and have FMP manage the change in notation for the data to the necessary 23:45. It seems back in FMP11 there used to be a LET Script step, upon which I would have (probably) been able to build a script to achieve what I desire... unfortunately, it seems LET doesn't feature in FMP14 scripting -and I aint smart enough to figure out what its alternative is now. Any suggestions/advice gratefully received. Regards
10. ## Script a SEARCH across 4 Fields

Greetings. New to the forum, using FMP14 on a Mac running Mavericks, FMP novice, aviation industry. Right... I think the best way to get to where I need to be is provide a little background: I'm working in what would politely be termed a 3rd World area -Papua in Indonesia, to be precise. There is not a lot in the way of structured organisation at a professional level here. I have developed (over the last 4 years or so) a database of navigational waypoints which we use here daily. I have sourced the data from a fairly diverse range of sources and now have a database that is really quite useful, after having undergone several structural changes as I have learned where the original data has come from, conventions that were used to build it and of course, proven the validity of the data myself before using it operationally. Therein lies the problem: Many organisations have contributed to the entirety I now have, with little-to-no consultation or cooperation between them. I have waypoint identifiers I have had to: 1. Record existing data and remove duplicates 2. Assign a unique identifier to each waypoint 3. Sort the existing (not necessarily unique) name into an appropriate field, where possible i.e. ICAO and/or IATA identifiers, or another field to contain the existing name where it fits no other field... this because many existing documents still refer to these "old" identifiers, so they still need to be stored and accessible when required. Then comes my problem: I have to be able to search them and pull up all the relevant information on the waypoint. I am often provided only partial information with a request for data, so unless I'm Very lucky, I wind-up executing anything up to a dozen Find's on 4 fields to get where I want to be! Frustrating and costing a Lot of time. I have over 900 waypoints recorded here now. What I would like to be able to do is: Execute a Script that will pop-up a box that I can enter the known search parameters into, then have it search the 4 fields for that string and return the results. Sounds pretty simple when you say it quickly ;-) I've spent a lot of time searching & trying whatever I could find, without success. Many "hot leads" have fizzled, having been suggested or written for versions earlier than 14. I'm far from expert in FMP or Script writing... but am able to follow simple instructions, as long as you type s l o w l y ;-) Many thanks in advance for any suggestions, tips or pointers -and thanks for your patience in reading this far ;-)
×
×
• Create New...