NX8.0.3 MP9 Windows 7 x64 Native
The poster in thread561-122048 asked a question which I'll repeat here, since it wasn't answered directly. In the NX Documentation on Large Assembly management, it is recommended to point NX to a text file called "ug_search_dirs.dat" in which you maintain your list of search directories. The NX Doc recommends being as explicit as possible about the specific directories to search, to reduce the time spent searching through unnecessary directories. This would seem to dis-recommend maintaining this list in the ug_load_options.def file. I'd happily implement the ug_search_dirs.dat approach but as the OP stated, I can't get NX to parse the list of directories in my ug_search_dirs.dat file.
Can anyone give explicit step by step advice on how to get this system working? Would appreciate it very much!
For reference, here's the link to page from NX Documentation:
/UGDOC/html_files/nx_help/index.html#uid:index_assemblies:id668591:id668636:best_practices_bp_lrgassy_loadops:best_practices_bp_lrgassy_load_method
and an excerpt:
"
(native NX only) In a production environment running NX, it is usually necessary to use the From Search Folders option when you are in native mode, because most assemblies reference standard and released parts that are organized into central folders or directories away from your working directory. Load performance is proportionally affected by the number of directories and files that must be searched. Naturally, you should minimize the directories searched, but also the number of files in each is important. On some operating systems, as the number of files approach 1500-2000 per directory, significant file access degradations occur.
It is recommended that parts be kept separate from other files, so that search paths be limited to just these areas. The ellipsis suffix () can be used to search all subdirectories, but this is generally not recommended because additional time will be needed to check for more subdirectories at every level encountered. (This includes linked directories on non-Windows and mounted volumes on Windows.) For maximum performance, you should use only explicit search paths.
Furthermore, we recommend that system administrators maintain the search paths in text files, rather than requiring each user to maintain search paths. By adding subdirectory names, one per line, in a file called "ug_search_dirs.dat" and setting the search path to find at least this file, you can achieve the following advantages:
You can control the order and number of subdirectories searched.
You can place additional "ug_search_dirs.dat" files in deeper subdirectories to cascade searches.
The time required to test for subdirectories is avoided.
You can write scripts to change the "ug_search_dirs.dat" file as desired.
As companies grow, the time will come when a Product Data Management (PDM) system, such as Teamcenter Integration, will be necessary. PDM systems which are backed by powerful database engines can access large amounts of data without the above (and many other) limitations. We recommend implementing a PDM system as early as possible to limit transition efforts.
"
The poster in thread561-122048 asked a question which I'll repeat here, since it wasn't answered directly. In the NX Documentation on Large Assembly management, it is recommended to point NX to a text file called "ug_search_dirs.dat" in which you maintain your list of search directories. The NX Doc recommends being as explicit as possible about the specific directories to search, to reduce the time spent searching through unnecessary directories. This would seem to dis-recommend maintaining this list in the ug_load_options.def file. I'd happily implement the ug_search_dirs.dat approach but as the OP stated, I can't get NX to parse the list of directories in my ug_search_dirs.dat file.
Can anyone give explicit step by step advice on how to get this system working? Would appreciate it very much!
For reference, here's the link to page from NX Documentation:
/UGDOC/html_files/nx_help/index.html#uid:index_assemblies:id668591:id668636:best_practices_bp_lrgassy_loadops:best_practices_bp_lrgassy_load_method
and an excerpt:
"
(native NX only) In a production environment running NX, it is usually necessary to use the From Search Folders option when you are in native mode, because most assemblies reference standard and released parts that are organized into central folders or directories away from your working directory. Load performance is proportionally affected by the number of directories and files that must be searched. Naturally, you should minimize the directories searched, but also the number of files in each is important. On some operating systems, as the number of files approach 1500-2000 per directory, significant file access degradations occur.
It is recommended that parts be kept separate from other files, so that search paths be limited to just these areas. The ellipsis suffix () can be used to search all subdirectories, but this is generally not recommended because additional time will be needed to check for more subdirectories at every level encountered. (This includes linked directories on non-Windows and mounted volumes on Windows.) For maximum performance, you should use only explicit search paths.
Furthermore, we recommend that system administrators maintain the search paths in text files, rather than requiring each user to maintain search paths. By adding subdirectory names, one per line, in a file called "ug_search_dirs.dat" and setting the search path to find at least this file, you can achieve the following advantages:
You can control the order and number of subdirectories searched.
You can place additional "ug_search_dirs.dat" files in deeper subdirectories to cascade searches.
The time required to test for subdirectories is avoided.
You can write scripts to change the "ug_search_dirs.dat" file as desired.
As companies grow, the time will come when a Product Data Management (PDM) system, such as Teamcenter Integration, will be necessary. PDM systems which are backed by powerful database engines can access large amounts of data without the above (and many other) limitations. We recommend implementing a PDM system as early as possible to limit transition efforts.
"
