"Using Pro/LIBRARYACCESS To Reduce The Number Of "search_path" Options For Assembly Retrieval"

Assembly retrieval from a database containing several directories, normally requires the use of the config.pro option "search_path" when the assembly components are distributed between these directories. When retrieving an assembly, Pro/ENGINEER looks for the assembly component models in the current directory, in the assembly directory and in each directory listed by the "search_path" options, in the order in which they are listed.

If a component model is stored in the last directory listed by "search_path", Pro/ENGINEER will search in all of the other directories before finding the model. This can generate performance issues when searching large quantities of data stored on shared network drives.

E.g. an assembly containing 50 models stored in the last directory of a list of 50 "search paths" on a network shared drive, Pro/ENGINEER will access the network approximately 2500 (50 x 50) times to retrieve the assembly.

Furthermore, since the contents of each directory is not known, each time the operating system must "present" a directory listing to Pro/ENGINEER. There are some known issues regarding this: http://support.microsoft.com/default.aspx?scid=kb;EN-US;q177266

Currently, there are some config.pro options that can help in these cases:

nt_cache_dirs see TAN 18949
dir_cache_max see TAN 110519
disable_search_path_check see TAN 110519

NOTE: The last two options concern performance when creating new files. Please read these documents attentively before applying these options.

A possible alternative is to use a catalogue file which lists all (or a part) of the models contained in the database with their complete paths and prevents setting the "search_path" option for these directories.

This requires the optional Pro/LIBRARYACCESS module, which works as follows:

     1-Whole database is organized in different sub-directories, under a top-level directory.       

     2-PRO_LIBRARY_DIR variable has been defined both for system and in the config.pro and lists the 
  path to the database top-level directory        

     3-A recursive purge to avoid redundant names and a check to avoid files without double extensio 
 ns in the database sub-directories (more details below) have to be performed.      

     4-The command <Pro/ENGINEER Load Point>/bin/pro_build_library_ctg have to be executed fro 
 m an OS shell: this creates a catalogue file <top level directory>.ctg. This file will  
 list all the files (and their paths) in the database under the directory indicated by the PRO 
 _LIBRARY_DIR variable.  

ADVANTAGES:
The most important advantage is that the "search_path" option becomes obsolete. Searching for a model, Pro/ENGINEER directly obtains the path from the catalogue file, dramatically reducing the quantity of accesses to the disk and the network.

The solution is reversible - it is possible to switch back to the "search_path" method without any problems.


DISADVANTAGES:
Pro/LIBRARYACCESS does not support double extensions,
e.g.
C:\database\dir1\part.prt
C:\database\dir2\part.prt.1
C:\database\dir3\part.prt.2

are seen as 'part.prt' so, when creating the catalogue, the following message could appear:

Warning: Found duplicate filenames, part of type prt,
Duplicate file 1: C:\database\dir1/part.prt
Duplicate file 2: C:\database\dir2/part.prt
Duplicate file 3: C:\database\dir3/part.prt
Please rename either one of these files and regenerate the catalog again.

NOTE: this a warning message only and does not prevent the retrieval of the models. However, models without double extensions (i.e. part.prt) will be considerated as more recent than parts with double extension (i.e. part.prt.2). This is the inverse of the behaviour of the "search_path" option. Therefore, it is strongly recommended to complete step 3 above.

Another issue can be the size of the catalogue file for huge databases.

Once the database is 'cleaned', a solution can be to use some residual directories listed by "search_path" options, in which the new models are created and stored until the CAD manager purges and moves them to other directories and re-runs the pro_build_library_ctg script.


PARTICULARITIES:
What happens when using the "search_path" options AND Pro/LIBRARYACCESS?

Search order: first the "search paths" and then the catalogue. So the most recent model in the "search paths" will be retrieved first, even if the latest model with the same name is found in the catalogue.
E.g. if 'part.prt' is in the "search paths" in versions 'part.prt.10' and 'part.prt.11' and in the Pro/LIBRARYACCESS catalogue with version 'part.prt.15', Pro/ENGINEER will retrieve 'part.prt.11'.

What about Family Table Instances and Index files?

When retrieving assemblies, there is no problem: the assembly contains information about the generic name stored in the known form "instance_name<generic_name>.prt": the generic name and path are read from the catalogue file and the instance retrieved properly.

When retrieving models manually, using #File / #Open and typing the name of the part in the corresponding field of the File Open dialog box, the behaviour will be different when using "search_path" options or Pro/LIBRARYACCESS.

Using "search_path" options, if the instances are properly indexed in the index files of the sub-directories, the name of the instance in the model name field is enough. Hit the ENTER key and the instance will be properly retrieved.

Using a Pro/LIBRARYACCESS catalogue, Pro/ENGINEER will search in the catalogue file which does not contain the names of the instances. So, in this case, the name of the generic is also necessary: type "instance_name<generic_name>.prt" then hit ENTER key to retrieve the model properly.

NOTE: Using the instance accelerators (which are listed in the catalogue file) does not change this behaviour. The instance accelerators influence only the retrieval itself but not the search process.

If this behaviour causes a problem (the user needs to know the name of the generic to retrieve an instance in this way), there is a workaround: merge, manually or using an user defined script, the index files from the sub-directories in one complete index file in the top-level database directory and name this file <name of the top level directory>.idx

VERY IMPORTANT: Maximal number of IDX entries (total amount of all Instances of all Parts/Assemblies stored inside given directory) must be about 500000

This will allow to Pro/ENGINEER to find in the catalogue the generic of any instance and to retrieve it properly.


FAQ (Frequently Asked Questions):
Is using Pro/LIBRARYACCESS instead of "search_path" options for assembly retrieval faster, if so, by how much?

Time saved cannot be predicted and depends upon the following factors:
-network speed,
-number of directories,
-number of files per directory
-catalogue file size
-etc.

Is it necessary to create "MNU" files in the library sub-directories?

It is not necessary to add *.mnu files in the library directories. This is necessary only if you want load models manually performing #File / #Open / #Pro/Library Dir….


OTHER:
Refer to the following for further information about using the Pro/LIBRARYACCESS module:

Suggested Technique for Installing Files from the Pro/LIBRARY CD and Creating a Pro/LIBRARY Catalog http://www.ptc.com/cs/cs_23/howto/ist990/ist990.htm