6 Replies Latest reply on Dec 4, 2014 3:58 PM by MarkGores

    Form problems



      Form problems


      I have a solution I'm building to record and store test data.  There is a

      Jobs table that holds info for each job

      Data Table that holds all of the data

      Tech table that holds technician info

      then a bunch of form tables for each type of testing.

      Each form table is related to Jobs with a JobID and to the Data table with a TestID

      In order to have the technician able to digitally sign a form, I set up a relationship between Jobs::pwGlobal and Tech::password.  Then set up a script that asks for the password (dialog box that has Jobs::pwGlobal as the input field) then sets the Form::TechID to the Tech::TechID from the look up.  It works fine on most of my forms, but on some the TechID doesn't populate once the password is entered. I can't find what is different about the relationships between the forms where it works versus those where it doesn't.

      Any ideas?


        • 1. Re: Form problems

          As a test, I put the Jobs::pwGlobal and Tech::TechID fields on each of the form layouts.

          With a valid password in the pwGlobal field a TechID is displayed on those forms where my script works and no TechID is displayed on the forms that I am having issues with.

          The Jobs::pwGlobal = Tech::TechID relationship should not be affected by the layout it is being displayed on should it?

          Each of the tables that the different form layouts are based on are related to the TO of Jobs in the same manner (Jobs::JobID = whateverForm::JobID)

          • 2. Re: Form problems

            Arrrrg.  After further testing I found that the issue was not because of the form table, layout or relationship.

            The issue was that somehow a blank record was created in the form table that was not related to the Job table.  Any form record in any form table works if whateverForm::JobID is valid.

            • 3. Re: Form problems

              The Jobs::pwGlobal = Tech::TechID relationship should not be affected by the layout it is being displayed on should it?

              Certainly. In each case the references toTechID will be evaluated from the context of a different table occurrence--the occurrence specified in Show Records From in Layout Setup.

              Each of the tables that the different form layouts are based on are related to the TO of Jobs in the same manner

              Better check that. Your test shows that there is some sort of relationship based issue that is keeping data from the related Tech record from being accessible on those layouts where this is not working. This can have one of three possible causes that I can think of:

              There's  a problem with a field definition such as a record not having the correct type, or index needed to serve as a functional match field in a relationship.

              There's a problem with a field's value and thus the records don't match as you would expect the to match as the values are not identical.

              There's an intermediate relationship link that is not functioning. If you have:
              Table A-----Table B-----Table C

              a Layout based on Table C cannot show data from Table A unless there is at least one record in Table B that both matches to the current record of C and at least one record in A.

              • 4. Re: Form problems

                Thanks Phil, that was it.  As I had just posted I had a blank record in the form tables that were not working.  When I create valid records they all work fine.

                The other "hole" in my solution is that I have the security options set for Technicians so that they cannot modify form records that have whateverForm::Signature filled in.  Most of the forms have portals to the data table.  While the fields based on the form table do lock properly, the data in the portals is still accessible.  For now I have a script that is set to run "on entry" for the portals that checks for signature and privilege set and "commits record" for those that shouldn't have access.

                Just wondering if there is a more elegant/proper way to do that.

                • 5. Re: Form problems

                  I I've used exactly that method, using OnObjectEnter with Commit to "bounce" the user back out of the portal. The most secure way to lock the portal so that new records can't be added is to add a validation option on the fields of the portal table that reject all input if there's a "signature" for the parent record.

                  • 6. Re: Form problems

                    So I'm not far off then.  Good to know.  All seems to works so far ...

                    Have an unlock button that only shows/works if Get(PrivilegeSet) = Full Access so that "Admin" can unlock a form by clearing the signature field if it's ever needed.

                    Now someone has asked me to tie their training record database into the system, which led to the idea of checking to make sure a technician is qualified to perform a test before allowing them to sign a form.  Uggg