3 Replies Latest reply on Jan 31, 2017 8:22 AM by philmodjunk

    export container field contents utility script performance issues

    ericjlindholm

      Hello!

       

      I have a utility script for exporting container field contents to preview.  the only script parameter is getfieldname(field).  I cannot export field contents with a calculated field name so I have a stack of if else steps to allow the script to export the correct field contents.  every time I add a new field, I forget to add the new code to the script.  The performance is fantastic but is script is ugly and forgetting to add the new code makes me feel dumb. 

       

      I tried to clean it up by creating a global container field in my globals table and doing the following:

       

      Set Variable [ $field; Value:Get(ScriptParameter) ]
      Set Variable [ $FilePath; Value:Get ( TemporaryPath ) & "/"& GetField ( $field ) ]
      Set Field [ Global::ClipboardContainer; GetField ( $field ) ]
      Export Field Contents [ Global::ClipboardContainer; “$FilePath”; Automatically open ] Set Field [ Global::ClipboardContainer; "" ]

       

      It works.... over the WAN it is SLOOOW compared to the other method.  I will test it on my LAN tomorrow but I am trying to optimize WAN performance as well. 

       

      Im sure there is some nuance to the set field script step when using containers and/or global fields.  that I don't know.  are there faster steps I could use?

        • 1. Re: export container field contents utility script performance issues
          philmodjunk

          Perhaps instead of adding more and more container fields, you could put just one in a related record. Every time you need another container, you add another record. This leaves you with a single field name to work with when exporting field contents.

          • 2. Re: export container field contents utility script performance issues
            ericjlindholm

            I do this with many of my a lot of my container fields. In this case, i need to make sure a few specific documents are on file for an entity.  In order to do what your suggesting, I believe I would need to keep the PK of the Doc record in my parent record and create a related TO that will show that doc only. 

             

            I want to validate about 3 docs per record and would need a TO per doc i want to validate.  I like this idea because I could "archive" last years docs into by just replacing the PK of the doc id in my parent record with the new doc.

            • 3. Re: export container field contents utility script performance issues
              philmodjunk

              Adding TO's is "cheap". A few more rarely make a measurable difference in performance and it's quick an easy to do.

               

              But a single relationship that matches by more than just a PK, such as a PK AND a type field is all you need to keep from setting up specific TO's. And this also supports the idea that should you need more docs, you just add more records (and more types)--all data entry changes rather than database design changes.

               

              And you might also use ExecuteSQL to confirm whether the record exists or not to validate whether such a document exists or not. Then you do not need any additional TO's.