Jump to content

jbante

Members
  • Content count

    614
  • Joined

  • Last visited

  • Days Won

    33

jbante last won the day on September 18

jbante had the most liked content!

Community Reputation

141 Excellent

About jbante

  • Rank
    member

Profile Information

  • Gender
    Not Telling
  • Location
    California

FileMaker Experience

  • Skill Level
    Expert
  • FM Application
    16 Advanced

Platform Environment

  • OS Platform

FileMaker Partner

  • Certification
    7
    9
    10
    11
    12
    13
    14
    15
  1. Quartile Ranks

    Then use stored number fields instead of calculation fields, and set each quartile field in a script that does separate sorts before setting each quartile field. A script also potentially makes it easier to handle ties, to address LaRetta's point.
  2. Thank you for the update!
  3. Is there an estimate of when a production version of a new build might be available? Weeks? Months?
  4. Quartile Ranks

    If you sort the records by contribution, you can set the quartile for each record with the calculation: Ceiling ( Get ( RecordNumber ) / Get ( FoundCount ) * 4 )
  5. The 5.06 build goes back to working normally in my tests on Mac & Windows clients. I'm reluctant to put this on the server without knowing how production-ready this build is.
  6. Now running ScriptMaster v5.052, I get the exact same error in all three contexts (Mac client, Windows client, Windows server).
  7. Is there a ScriptMaster version "5.052"? I just downloaded it fresh from 360Works yesterday, and it's only 5.05 (no 2).
  8. This isn't working in FileMaker 16 anymore. Does anyone have any good ideas why? The full function decompresses the contents of a container field and puts the result in a file: // SM_DecompressGZIPContainerToFile ( containerFieldName ; resultFilePath ) import java.util.zip.GZIPInputStream; import java.io.FileOutputStream; import java.util.io.*; InputStream fieldStream = new BufferedInputStream(fmpro.getContainerStream(containerFieldName)); GZIPInputStream gunzip = new GZIPInputStream(fieldStream); FileOutputStream fileOutputStream = new FileOutputStream(resultFilePath); byte[] buffer = new byte[1024]; int bytes_read; while ((bytes_read = gunzip.read(buffer)) > 0) fileOutputStream.write(buffer, 0, bytes_read); gunzip.close(); fileOutputStream.close(); return 1; This worked great until FileMaker 16 and ScriptMaster 5.05. Now it doesn't. I've tried it from the client (16.0.2) on Mac (10.12.6) and Windows (Server 2012 R2), and in server schedules and Perform Script On Server (16.0.2.212). Mac and Windows clients both report this stack trace: java.lang.IllegalArgumentException: You tried to create a QuadChar with a string of length: 0 at com.prosc.fmkit.QuadChar.<init>(QuadChar.java:52) at com.prosc.fmkit.types.FMBinary.getStreamTypes(FMBinary.java:389) at com.prosc.fmkit.types.FMBinary.getBestQuadChar(FMBinary.java:404) at com.prosc.fmkit.types.FMBinary.getBestInputStream(FMBinary.java:443) at com.prosc.beanshell.FMPro.getContainerStream(FMPro.java:58) at com.prosc.beanshell.FMPro$getContainerStream.call(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120) at Script1.run(Script1.groovy:1) at com.prosc.beanshell.GroovyFunction._invoke(GroovyFunction.java:158) at com.prosc.beanshell.GroovyFunction.invoke(GroovyFunction.java:136) at com.prosc.fmkit.Plugin.invokeFunction(Plugin.java:398) at com.prosc.fmkit.RegisterablePlugin.invokeFunction(RegisterablePlugin.java:178) at com.prosc.fmkit.Plugin.invokeFunctionNoErrors(Plugin.java:374) at com.prosc.fmkit.PluginBridge2$1.run(PluginBridge2.java:1059) at com.prosc.fmkit.PluginBridge2.doFunction(PluginBridge2.java:1072) at com.prosc.fmkit.PipeChild.lambda$handleMessage$9(PipeChild.java:297) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Server schedules and PSOS both report this, instead: com.prosc.fmkit.FmCalculationException: 106 at com.prosc.fmkit.PluginContext.evaluateExpression(PluginContext.java:192) at com.prosc.beanshell.FMPro.getContainerStream(FMPro.java:57) at com.prosc.beanshell.FMPro$getContainerStream.call(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120) at Script1.run(Script1.groovy:1) at com.prosc.beanshell.GroovyFunction._invoke(GroovyFunction.java:158) at com.prosc.beanshell.GroovyFunction.invoke(GroovyFunction.java:136) at com.prosc.fmkit.Plugin.invokeFunction(Plugin.java:398) at com.prosc.fmkit.RegisterablePlugin.invokeFunction(RegisterablePlugin.java:178) at com.prosc.fmkit.Plugin.invokeFunctionNoErrors(Plugin.java:374) at com.prosc.fmkit.PluginBridge2$1.run(PluginBridge2.java:1059) at com.prosc.fmkit.PluginBridge2.doFunction(PluginBridge2.java:1072) at com.prosc.fmkit.PipeChild.lambda$handleMessage$9(PipeChild.java:297) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) I get the same results when I reduce the function to just this: InputStream fieldStream = fmpro.getContainerStream(containerFieldName); return 1; Any thoughts?
  9. better way to go through data

    XSLT seems to me like it would probably be the fastest. Exporting the CSV to disc and importing can also be advantageous if your schema is already a convenient match for that or you're willing to adapt your schema for that. The built-in JSON functions have many virtues. Execution speed is not one of them. In every test I've run, GetValue on return-delimited lists leaves the built-in JSON functions in the dust. The MBS plug-in handles JSON differently in a way that makes it much faster (MBS does what I was hoping FileMaker would do with an in-memory data structure), if you're into plug-ins. If you like sticking with return-delimited lists, you can make the processing of a large list go faster by pruning the list as you go: Set Variable [ $value ; GetValue ( $list ; 1 ) ] Set Variable [ $list ; Replace ( $list ; 1 ; Length ( $value ) + 1 ; "" )] This makes the parsing of the whole list work in roughly O ( N^1.5 ) time, rather than O ( N^2 ).
  10. JSON Array payloads for faster syncing

    The new JSON functions have many admirable advantages for performing certain operations. Speed is not one of them. (Unless the serialized data format is JSON, there's nothing you can do to change that, and the only alternative parsing method is other built-in FileMaker functions.)
  11. Virtual list using JSON

    I have now. The 16.0.2 update does not change the performance characteristics of the JSON functions relative to return-delimited lists or repeating variables.
  12. Virtual list using JSON

    The JSON functions in FileMaker 16 have constraints the SortValues and UniqueValues do not. The JSON parsing functions check that the input they're trying to parse is in fact completely valid JSON. FileMaker has to do this to be able to return an error result when appropriate. You can't know if the outer-most structure in a JSON string is correctly terminated without starting at the beginning, checking every inner structure, and getting all the way to the end. Due to how the JSON format works, this requires stepping through the entire string for every single operation. (This could be resolved by FileMaker using a more efficient internal data structure for JSON in place of the raw string, but performance tests from a few folks suggest that FileMaker isn't doing this.) In comparison, the GetValue function only has to parse as many newline characters as it takes to get to the value you want, and it can ignore everything in a string after that point. With repeating variables, there doesn't need to be any parsing at all (depending on how you do it) — you can just use the whole content of the variable (repetition). The JSON writing functions have a similar constraint. They validate any JSON you had to start with, and then the JSON writing functions are somewhat fastidious in organizing the contents of their JSON outputs. You can make parsing nested structures in JSON less slow by parsing out inner structures, then getting the details from the inner structures, rather than pulling from the outer structure for every inner detail. This reduces how much total work FileMaker spends validating the JSON for each read. When speed is more important than simple code, do this: Let ( [ _dictionary0 = JSONGetElement ( $json ; 0 ) ; _0a = JSONGetElement ( _dictionary0 ; "a" ) ; _0b = JSONGetElement ( _dictionary0 ; "b" ) ; _dictionary1 = JSONGetElement ( $json ; 1 ) ; _1a = JSONGetElement ( _dictionary1 ; "a" ) ; _1b = JSONGetElement ( _dictionary1 ; "b" ) ] ; ... ) Not this: Let ( [ _0a = JSONGetElement ( $json ; "[0].a" ) ; _0b = JSONGetElement ( $json ; "[0].b" ) ; _1a = JSONGetElement ( $json ; "[1].a" ) ; _1b = JSONGetElement ( $json ; "[1].b" ) ] ; ... ) And for writing JSON, add as much in each JSONSetElement call as you can, rather than using many separate calls. Do this: JSONSetElement ( "[]" ; [ "[0].a" ; 1 ; JSONNumber ] ; [ "[0].b" ; 2 ; JSONNumber ] ; [ "[1].a" ; 3 ; JSONNumber ] ; [ "[1].b" ; 4 ; JSONNumber ] ) Not this: Let ( [ _json = JSONSetElement ( "[]" ; "[0].a" ; 1 ; JSONNumber ) ; _json = JSONSetElement ( _json ; "[0].b" ; 2 ; JSONNumber ) ; _json = JSONSetElement ( _json ; "[1].a" ; 3 ; JSONNumber ) ; _json = JSONSetElement ( _json ; "[1].b" ; 4 ; JSONNumber ) ] ; ... ) While these patterns make FileMaker's JSON functions less slow, it isn't enough to make them competitive with return-delimited lists or repeating variables for speed.
  13. Virtual list using JSON

    Technically, it could be done. As Wim mentioned, performance is a major constraint. The JSON functions are slow compared to the built-in functions for return-delimited lists, and very slow compared to repeating variables.
  14. "The San Diego Workforce Partnership (SDWP) seeks a contractor to support our team of FileMaker developers in the development, maintenance, and improvement of SDWP’s custom software suite." Quotes are due by 16 June 2017 at 5 p.m. PDT. http://workforce.org/rfps/2017/06/06/rfq-filemaker-pro-consulting-services
  15. FM 16 Variable Repetition limitation change?

    There are two types of solutions here: solutions with no risk of collision, and solutions where the risk of a hash collision can be resolved so that it has no negative consequences.
×

Important Information

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