Previous Next
Working Environments and cross referencing

After a brief note on RAM-based cross referencing, this section concentrates on issues relating to DB-driven cross referencing and Working Environments.

  • Regardless of which X-Ref technology you use, mixing X-Ref technologies within a Working Environment hierarchy does not work. This is because different files are used by each system, as shown under How the X-Ref subsystems work.

RAM-based cross referencing
Under RAM-based cross referencing, there are no special implications as far as Working Environments are concerned. This is because the X-Ref information files are maintained at project level.
When files are checked out/in they are reparsed, and the procedure for generating X-Ref information as described for this technology under How the X-Ref subsystems work is set in motion when queries are issued. As a result, multiple access is not a problem under RAM-based cross referencing.
DB-driven cross referencing and Working Environments
X-Ref databases are maintained at Working Environment level. Although only one X-Ref database is created per Working Environment, information sharing has to work across Working Environment boundaries. This implies that some sort of mechanism for controlling Read and Write access to database files has to implemented.
X-Ref database access control
Note that "accessing an X-Ref database" effectively means "opening Projects (with symbol information) in a given Working Environment, and thereby accessing the X-Ref database for that Working Environment and higher-level (Shared) Working Environments".
In the following, a number of points relating to database access control are listed, together with examples as they affect team development.
Where locking information is maintained
Locking information is maintained in a subdirectory of your Working Environments Configuration Directory (you set this in your Preferences) called
.snifflock . A subdirectory is created for each lockable Working Environment, this subdirectory takes the name of the Working Environment for which the locking information is maintained. All current Read access locks are stored directly in this subdirectory. Each of these subdirectories can have another subdirectory called lock . Any existing Write access lock on the Working Environment is stored in the lock subdirectory.
Lock file names have the following syntax:
lock. machinename. PID
If an attempt is made to access locked databases, files are created called
try.machinename. PID
These files are used by SNiFF+ to identify requests for X-Ref database access.
Maintenance of X-Ref databases
If, for some reason, databases become corrupt, SNiFF+ may be able to repair them. If the databases are irreparably damaged, they can be recreated from scratch by deleting the corrupt database files (see also Location of generated X-Ref information) and issuing a Force Reparse command.
The information in the X-Ref database is cumulative, that is X-Ref information for every project ever opened in a given Working Environment is stored in that Working Environment's database. The X-Ref information for any given project will only be removed from the database when the Project is deleted using the Delete Project command.
Synchronizing Working Environments
The correct order for updating/synchronizing Working Environments should always be maintained to avoid inconsistencies. This is
  • Shared Source Working Environment (SSWE)
  • Shared Object Working Environment (SOWE)
  • Private Working Environment (PWE)
Again: Whenever a higher-level Working Environment (e.g. SSWE) is updated, all lower- level Working Environments (e.g. PWEs) accessing it should (must) be subsequently updated.
This holds especially for DB-driven cross referencing. Apart from all other possible inconsistencies caused by out-of-sync Working Environments, cross reference information will also be inconsistent because, for performance reasons, internal database objects are shared among Working Environments.