Jump to content

Justin P.

Members
  • Content Count

    54
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Justin P.

  • Rank
    member

Profile Information

  • Gender
    Not Telling
  1. I have a uniqueness criteria for a particular number field, but the uniqueness is based on a combination of the number field with a state field (e.g. the number must be unique within all records for that state). I built a custom function to return a boolean if the number+state combination already exists in the database, and that CF uses a simple SQL query, Issue is that the CF seems to work flawlessly when tested via Data Viewer, but when inserted as the field validation calculation, returns a validation failure for any value entered. Can anyone enlighten me as a to a limitation here I may not be aware of? My work around path is a field level trigger to a validation script, but do feel like I am missing something. Cheers, Juz.
  2. All fair points. The client is dependent upon the host right now anyhow, so dependency for service continuity is built in there for now. Overall though, the client cost of decreased user experience (password resets) is less than the cost of setting up and maintaining external authentication. Will stick with the status quo. Thanks everyone.
  3. Its hosted on a third party FM hosting service that handles the FM Server licensing, Datatrium. Only basic access to logs, file push/pull, though I suppose I could ask if they offer any authentication services? Is that common?
  4. I thought as much, thanks Jeremy. The solution belongs to a very small company, they don't run any local servers, use Office 365 and that's about it. Any recommendations for a lightweight external/web based authentication service?
  5. Have a hosted solution where all users are able to modify their own passwords, and FM is handling all the user authentication. Am upgrading that solution, but just realized that when I push the new solution live, I do not have access to the user passwords, so they will have to be reset (or will be equal to whatever they were when the base copy for the upgrade process was taken). Anyway around this (I assume not, as it would compromise security if admin was given access to view passwords)?
  6. Thanks for the analysis everyone. dwdata: was wondering about the root cause of the crashing more than anything. I have already implemented a work around (which was to remove the script trigger and force a button click for update) which is working for now. LaRetta: Awesome suggestions, thanks. The join was a rush job for the demo, forgot to change one of them.But the IsValid v IsEmpty is good advice.So if the Child Table layout is corrupt, it is only manifesting in this very specific circumstance (I use that layout for many other operations within the full file). Because it took so long for this issue to show up in testing, and it is such a specific combination of script/popover/layout, I don't have an easy way to backtrack and rebuild from last good version. Nonetheless......I have a workaround that is operating without issue right now, but obviously am worried this will manifest in other script calls, so will replace the layout. It is easy to replace, it is a blank (no fields) layout for internal operations, just got to catch all the references to it in the DDR first.Thanks again!
  7. Here's a demo file where the crash is repeatable (at least on my iMac and MacBook), just the bare basics that still showed the behavior. Also a few workarounds shown (basically, avoid the script trigger). All crash scenarios are related to a changed field within a portal, then dismissing a popover with a script attached (well, at least this Go To Layout script) before saving the field change. Steps are listed within the demo file. This file instructs you to dismiss the popover by clicking within a portal row. I also have seen the crash in my larger solution when clicking outside the popover and outside the portal, but was not consistent, and not replicated here. Additionally, I tried redirecting the GTL to the main layout (not a different layout), and this stopped i from crashing. So the actual command in the script has something to do with it. Curious to know if this doesn't crash for your environment! 2015-09-02 Crash Demo.fmp12
  8. Thanks LaRetta, very much appreciate the assistance. I will attach a cut down version of the solution here as soon as I can prep it. My suspicion at the moment is an interaction of a modified field and dismissing a popover to trigger the script. If I update a qty, click outside to save it, and then activate and dismiss (trigger) the popover, will usually not crash. But if I click straight from the qty field to the popover, crashes.
  9. LaRetta: thanks for the notes. Recover reported it as clean. I was not aware of recovered files being unusable, but will note that for future. Update 2: I think this is related to the popover interacting with the script. If I attach the same script to a button or field, no crash. But if I attach the same script to a completely new blank popover button, it still crashes. The oddity here is that this is an introduced instability, as the exact same popover worked perfectly well for months, up until I tried rewriting the script.
  10. Additional tests: Duplicating the script and calling the copy instead of the original made no difference.Changing the GoToLayout command to use a different layout made no difference.Copy all the script steps into a new blank script, try calling that one, which I thought would work, but made no difference.Exasperated!
  11. In the midst of trying to tune a solution for better WAN performance, I started to get consistent FMPA v14.0.1 and FMPAv14.0.2 crashes with a particular script. The type of crash that kills the whole Filemaker app (on Mac OS X 10.10.5). This was not a problem previously, but seems is now consistent for this one action. The actions are related to modifying a value within a pop-up, and then running some triggered scripts upon dismissing it. I laboriously traced through a bunch of scripts by gradually moving around an Exit Script step and found that the offending command is, believe it or not, a Go To Layout command. If I leave it in (even if I replace it with a new line for same layout) I get the crash, if i comment it out, actions continue. Behaviours: Tested it on a local machine and hosted, crashes the client FMPA version each time.Deleted the offending GTL command and wrote that line again, same result.The layout itself is used for other scripts, haven't noticed other crashes.A recover on the file found nothing of note, but recovered file crashes also. Fearing record corruption, I tried creating a clone, populated a few new records, and tested it again, same crash result.If i step through this using the debugger, no crash happens. Memory management issue or similar?I have a few more things I will try for hope's sake (e.g. rewriting the whole script), but wondering if anyone else has seen script caused crashes, and what they may have done to get around it? This and very inconsistent WAN performance slowdowns (<0.5 second logged for an action, that every now and then takes 10 seconds), been really getting the better of me! Thanks for any advice.
  12. FYI that I resolved the first part of this issue ( portal not displaying) by broadening the Fielmaker user permissions (not trying to limit at the record level using Security, instead having to fudge it at the layout and display level). The second issue (on particular child table field not displaying) is still vexing me though. Changing field permissions made no difference their. May just have to work around it by storing it in the Orders table, and not having it be dynamic. Weird one! Cheers, Juz
  13. I have a simple dashboard portal using SELECTOR (global) -> CONNECTOR (table::ID). I have noticed that the portal does not display records even though the global selector has IDs populated (global can be seen in data viewer), but this occurs only for a non-Full Access group of users and only when hosted on a remote FM Server (third party host). I have tested the counter approaches to both of those conditions (access rights, local v server) and shown that it works in all other ways: when copied to local machine, the particular user group see the expected records in the portal fine.when I login to the hosted solution as a full access user, I see records fine in this same portal.Thought it was just the portal filter (which I use to filter down to user permitted records), but turning that off makes no difference to this issue. After that, I ran out of ideas on how to fix this one very fast. Anyone seen this behaviour before? Also noticing another oddity that has similar conditions: I have an field (Account::Code) that is visible to this user group when on an account detail layout, but when I try and view it from a related table layout like Orders (e.g. Orders_Account::Code), it does not display, once again just for this non-Full Access user group and only when hosted. Makes me think this is relationship privileges based, but no idea where to look and no idea why this would only affect hosted version. Appreciate any wisdom! Cheers, Juz
  14. Justin P.

    Small SQL Query Help

    You nailed it Kris, thanks. In reference to the "sum of a sum", one sum is the invoice total (sum of line items), the aggregate chart is sum of all invoices.
  15. Cannot get to the bottom of this one... This ExecuteSQL query works fine (all escape characters etc removed for clarity) SELECT a."Month Name", SUM(a."Total") FROM "Orders" a WHERE a."Year" = ? GROUP BY a."Month Name" I have a Month Number field also... Month Number = Month (date) But adding that into the query then kills it completely (returns "?") SELECT a."Month Number", a."Month Name", SUM(a."Total") FROM "Orders" a WHERE a."Year" = ? GROUP BY a."Month Name" I have checked, seems to be appropriate data in all the fields. Any clues? Driving me batty...
×

Important Information

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