This special topic discusses the following interconnected concepts:
Application Locking — This concept limits who can run and when they can run which applications.
Dynamic Tables — This concept dictates one of the rules governing application locking.
Deltek has assigned an application locking code to every function in Costpoint. The code can be one of the following:
Single — This code means only one user may run the function at a time.
User or Restart — This code means many users can run the function at the same time but each user must be logged into Costpoint with a different user ID.
None — This code means many users may run the function at the same time with no restrictions.
When a user starts a function with either a single or user/restart lock code, Costpoint records the fact that the function is open and who opened it. When another user, or the same user on another computer, tries to start the same function, Costpoint checks the log and does allow the startup of the second request if the new user violates the application's locking rule. That is, if the application's locking rule is single, then the new user is not allowed to start up the function. This second user receives this message: 'You cannot access this single user function because another user is working with it.'
If the application's locking rule is user and the second user's ID is the same as the user ID under which the executing function's login was made, the second workstation is not allowed to start up the function. This duplicate user receives this message: 'You cannot access this function because you are already working with it on another workstation.'
Locks are put on functions for technical reasons. The less restrictive locks, user and restart, are required on those functions that use dynamic temporary tables. Dynamic temporary tables are worktables created and dropped in the same application. Since they are temporary and built as part of the process, and since there can be multiple copies of them at one time (that is, one copy for each user running the function at a given moment), Deltek decided to build the tables in the tablespace of the user running the application. This way, Costpoint knows whose table is whose. But this also means that a user cannot run the function with the same user ID on more than one workstation. (The same-named table cannot exist more than once in a tablespace.)
Those functions with the most restrictive lock, single, may also use dynamic temporary tables, but they are more stringent for two other reasons. One reason is that the functions write to permanent worktables that do not know whose records are whose. If two users were running the same application, their records would become mixed up and the results would be unpredictable.
The second cause for single application locks is to prevent the possible shutdown of the database. Some functions, if run by more than one person at a time, lock the database. For example, when two people are running the same posting program, they are both selecting from the same ledger and writing to the same ledger. The contention for these records bottles up the database so that the database stops responding to anyone, and single locks result.
From time to time, a function will be closed without the normal shutdown procedures taking place. This usually happens when the workstation is turned off or the workstation loses power with the function still active, or the database shuts down. In these situations, the application remains locked; anyone attempting to run the application after the abnormal close receives the message that someone is already working with it. To remove the lock, clear the original user's session from the list of logged-in Costpoint users on the Clear Users screen. Clearing users frees up the license count and removes application locks.
To alleviate some of the nuisance of the user side effects, Costpoint has a variation of user locks called restart locks. Restart locking is applied to those reports and/or processes that does not corrupt data in the database if they are resumed after an abnormal termination.
Restart locks work like user locks except that your system administrator does not have to clear the original user's session before the same user can restart a function. The message a user gets when trying to resume an aborted function is: 'You are already working with this function on another workstation. Select OK to close down that session and continue with this Startup, or Cancel to abort this Startup.' If you click OK, the other application that is/was running is stopped and the function screens appear. If you click Cancel, the function's screen does not appear.
There is one residual drawback to the restart lock. The prior connection still uses up a license. The only way to free up the license is to have your system administrator remove the prior session using the Clear Users screen. Let your system administrator know whenever you restart a restart-locked application so that he or she can clear your prior connection at a time convenient for them.
Restart locks thus have two benefits:
Users do not have to wait for your system administrator to unlock the aborted function.
When the resumed session is completed, the orphaned dynamic temporary tables are dropped.
If you need to find out what type of locking code has been assigned to a function, connect to the database through SQLTalk using the User ID of DELTEK. Then issue the following command:
SELECT S_LOCK_MTHD_CD FROM S_APPL_FUNC WHERE
FUNC_TITLE_NAME = 'function title';
'function title' must match exactly the name of the function as it appears on the Navigate screen. That means entering the exact spacing and upper- and lower-case letters.
S_LOCK_MTHD_CD must be N for no locking, S for single locking, U for user locking, or R for restart locking.