Temporary files and session numbers

Many ACCPAC Plus systems use temporary work files to do interim processing or sorting of data during the normal processing cycle. This is also true of Inventory Receipts.

IR uses mainly 'IRW' and 'IRT' as temporary file prefixes in processing orders, receipts, returns and adjustments (and some other functions). The filename is built by the system from "prefix+session-number" for each session in Accpac. Thus, if you enter Accpac alone your session number will be 1 and your temporary IR work files will be IRW00001 and IRT00001. The next person in Accpac would be session 2 (IRW00002, IRT00002). If the first user uses F4 to open a new Accpac window (session) it would now be session 3 (IRW00003, IRT00003), and so forth. Note, the session number is assigned in Accpac by the WSM and not by IR.

Two symptoms are typical of session errors - Cannot delete the temporary file, and lines are not what were entered by this user. These are very typical to some users using the same session number and therefore the same temporary work files. This can only be caused if Accpac is not aware of all users on the system. These functions are controlled by the task and semaphore table files, which is pointed to in the PROFILE.LD4 file. The PROFILE.LD4 file is stored in the \ASP directory on the drive on which the Accpac programs are stored.

Now, when Accpac program files are installed in separate locations (workstations or even remotely via Terminal Server or PC Anywhere) it is necessary for the systems to be 'pointed' to the same spot so they would use the same table files. This is done in the PROFILE.LD4 file. In a 'normal' installation all users would be using the same program files (and therefore the same PROFILE.LD4 file) and thus would access the same table files.

We have encountered situations where Accpac has been installed at different workstations (and by the way, there is no logical reason why and offers no benefit to the average user) and when looking at the profile files all seemed well enough. The problem was that the users would MAP network drives differently, so drive G: on one users system would not necessary be drive G: of another. Look out for this.

 

or email info@unidevco.com with questions or comments about this web. Last modified: November 22, 2006 Copyright © 2000 - 2005 Uni Development Company Inc. All rights reserved.  All other marks are trademarks or registered trademarks of their respective companies.