9 Replies Latest reply on Jul 9, 2010 3:34 PM by philmodjunk

    Opening script user log

    Radcon

      Title

      Opening script user log

      Post

      Hi,

      I have a multi-user file that is hosted by a fmp server; I am not the administrator of the server, but I do have full admin rights for the file.  I wrote a script that is supposed to be launched when a user opens the file.  This script creates a new record in a history table, auto-enters a timestamp and the user firstname&lastname from a related table of permitted users. Most of the time it works fine, but sometimes users can log on and nothing is recorded;  I think the script is mis-firing.  What kinds of things could be causing this?  What troubleshooting techniques do you recommend?

      Thanks for any ideas!

        • 1. Re: Opening script user log
          philmodjunk

          It would help to see your script. You can copy and paste from a database design report if you have filemaker advanced or you can print the script to a PDF and use Acrobat Reader's text tool to select and copy the script to the clipboard for pasting.

          The only possible "misfire" I can think of is a possible record lock if two users log on simultaneously and this script attempts to modify the same record for both users.

          • 2. Re: Opening script user log
            davidhead

            Does every user privilege set have the right to create log records? In other words, is this a security setting issue?

            When you say that they log in and nothing is recorded, does it actually create a new empty record or is there no new record?

            • 3. Re: Opening script user log
              Radcon

              I wondered about the privileges sets also.  I looked at them again and, best I can tell, they look ok.  No record was created on two occasions.  I have not been able to duplicate the problem on my own.  The times it happened I was talking on the phone with the other person whose log-in was not recorded, so it may be possible that we both were trying to log on at the same time.  How much elapsed time could be considered "at the same time"?  milliseconds, fractions of a second, or even several seconds? The network is 10base2.  The script:

              Perform Script [ “Lock ALL records” ]  (This sub-script takes a seemingly long time to complete)
              If [ Get ( PrivilegeSetName ) = "[Full Access]" ]
              Install Menu Set [ “RME Menu Full” ]
              End If
              Go to Layout [ “WHO HISTORY” (Who History) ]
              New Record/Request
              #Facility_ID, First&LastName, Get(AccountName) are auto-entered upon record creation
              Set Field [ Who History::DB_Action; "User Logged In" ]
              Set Variable [ $$UserScope; Value:Permitted Users::Facility_ID ]
              Sort Records [ Specified Sort Order: Who History::zzID; descending ][ Restore; No dialog ]
              Go to Record/Request/Page[ First ]
              Go to Layout [ “Splash Entry TOC” (Items) ]
              Perform Script [ “Initial Set window size” ]

              • 4. Re: Opening script user log
                philmodjunk

                What does the script "Lock ALL records" do? (and why would you need it just to log new users?)

                Since the info is logged in a new/record the record locking possibility I suggested should not be an issue here as each user is logging info into a different record.

                I see you have the script installing a custom menu set. Any chance that the menu set in place for the non full access users does not include the "new record" menu item in the records menu? I suspect that removing that item, will disable the new/record script step.

                • 5. Re: Opening script user log
                  Radcon

                  What does the script "Lock ALL records"  do? (and why would you need it just to log new users?)

                  It sets a lock field =1, and loops to the next record...      I don't need it to log in new users, but the script runs when the file is opened (File Options, Open/Close,When opening this file, perform script), and when a user opens the file via a "opener file", I want all the records to be locked so that data is not casually changed.  Certain users can unlock individual records as needed for editing; I just don't want editing to occur without the user being reminded that they are about to make changes to the data.

                  I see you have the script installing a custom menu set. Any chance  that the menu set in place for the non full access users does not  include the "new record" menu item in the records menu?
                  The "new record" menu item was modified to read "New Item" and the "Delete Record" menu item was removed.
                  Again, this all works most of the time,(at least I think it does- the integrity of the log is in question here) and I do appreciate your suggestions because they may trigger a thought as to what might be different in the couple of occasions where no new record was created.
                  • 6. Re: Opening script user log
                    philmodjunk

                    I suggested a look at the custom menu set because you appear to select different menu sets for different users and that might result in a script that works for some users and not for others. Renaming the menu item won't be a problem, if you change its behavior, it might.

                    Since you have filemaker advanced, have you tried running this script with the debugger enabled? You can launch filemaker without opening the file, enable the debugger and then open the file to see a script set to run on open in the debugger. You can even enter a limited access password when the file opens and still see the script in the debugger.

                    Doesn't seem to be the issue here, but I don't see why you need to set a value to lock all records. Couldn't you just put a 1 in this field and keep it that way changing it only to unlock a record and then changing it back when the record is committed? That would avoid the long delays in getting the file open when you have a lot of records to "lock".

                    • 7. Re: Opening script user log
                      Radcon

                      Renaming the menu item won't be a problem, if you change its behavior,  it might.

                      And that might be the answer, but I won't know until I go back to work next Thursday.  I think that the "New Item" menu item actually launched a script that created a log entry also, but I have since renamed some tables and deleted others, so this is something I need to look at for sure.  I haven't seen a "item added" log entry in quite a while, so either that script was never attached to the menu item, or it is (more likely) a script with bad references.

                      Couldn't you just put a 1 in this field and keep it that way changing it  only to unlock a record and then changing it back when the record is  committed? That would avoid the long delays in getting the file open  when you have a lot of records to "lock".

                      I would like to discuss this further, should I start a new thread? I definitely would like to get rid of the overhead of looping through all the records on a frequent basis, but I am concerned that a user might un-gracefully exit the program before the record lock field was changed back to 1 and that somehow a 0 or Null ends up where a 1 should be.  Are my concerns groundless?

                      • 8. Re: Opening script user log
                        philmodjunk

                        I think opening a new thread would be a good idea. Start with a detailed description of your locking strategy and reasons for it. A new thread will invite participation by others besides myself.

                        • 9. Re: Opening script user log
                          philmodjunk

                          "...I think that the "New Item" menu item actually launched a script that created a log entry also, but I have since renamed some tables and deleted others, ..."

                          I'd definitely check that script. I believe your New Record/Request script step is triggering this New Item script and it may be doing something very different from creating a new record in the current layout as you would otherwise expect.