Use of SolidWorks Task Pane
This features requires SolidWorks 2006 or better and it is enabled through the option:
User Options ® SolidWorks®Show DBWorks Task Pane
DBWorks installs a custom Task Pane in the SolidWorks Application, similar to the search dialog.
Please note: data is not populated if you don't activate manually the pane.
More, the standard right-side tool bar of the DBWorks Browser can now be displayed as a Task Pane of SolidWorks 2006.
This feature is automatically activated by checking the option:
User Options ®SolidWorksShow DBWorks Shortcut bar Task Pane
Now you can see same columns displayed in the main DBWorks Browser Project Tree also in the DBWorks Feature Manager Tree and in the Document Page Project Tree.
As a consequence, the option:
User Interface ® DB Feature ManagerAlways Show Quantities in DBWorks Feature Manager
has become obsolete, and it has been removed from the Options.
More, some other options has been renamed because of their application among all trees.
A dedicated icon has been added to mark cut-list items:
Always use 1st level parent configurations
A new option has been introduced:
Configurations®Always use 1st level parent configurations
Any derived configuration will refer to the record assigned to its 1st level parent configuration
Support for Macros in the Configurations
Support for macros has been added to the option:
Configurations®Save configurations only of components with configuration names …
This feature follows same rules of the Data Input®Macro definition for configured record ID ( even scripts ) in the parameter for filtering the configurations to be saved by DBWorks
Tree Page’s “Volo View” tab replaced with MwClientView.dll
Since Volo View is no longer supported by Autodesk, the standard “enhanced” viewer will use the proprietary MwClientView.
Toolbar Reload functionality
The Toolbar Reload functionality is now implemented even in DBInventor.
More, two new options are available in the Reload Notification dialog:
Never notify me again in this session
Automatically reload all next components in this session
Enhancements in the Tree Page's Revisions history Grid
- RMB®Activate: activates the currently selected revision; if the new option Revisions®Files® Always ask the modality on the ACTIVATE of an older revision is checked, a message box asks for overwriting the current working file or creating the new revision in a separate directory
- RMB®Activate and create a new revision: activates the selected revision by overwriting the current working file, and, if successful, creates a NEW revision record based on the just activated revision.
- Enhanced tooltips showing both the REVISIONS record information and the Preview of the revision file
Enhanced definitions for Visual Cues matching values
It is now possible to define SQL expressions in the Visual Cues definition file (regular expressions are already supported for a single field value matching).
To define a dynamic SQL query, the @SQL[<n>] field name has been introduced. It must be a unique index (e.g. @SQL1, @SQL2, ...) if more than one conditions are set .
It is also possible to assign the PARENT_CHILD table for the condition, by prefixing the condition value with the name of the parent_child table enclosed between rounded brackets ( like "(PARENT_CHILD)" ); the Visual Cues referring the PARENT_CHILD table can be visible ONLY in the Tree interface.
Remarks: due to an every-single-row database query action, the overall display performance of both the Tree and Grid controls can be affected when one or more @SQL conditions are present in the Visual Cues definition file
- Condition on the DOCUMENT table
Suppose you want to override the default Gold square of a released document, to better differentiating the state of Major revision (defined with literals between A to Z, with no dots, like "A") or Minor revision (defined as Major plus a dot and a number, like "A.1" );
for such case, the Visual Cue definition could be:
"@SQL1","STATE='RELEASED AND REVISION LIKE '[A-Z].[0-9]'","minorRevision.bmp",12,1,0,-4
- Condition on the PARENT_CHILD table
Suppose you want to highlight components for which the parent-child MAKE_BUY value is 'NO_BOM':
Specific icons for any type of document are now displayed in every interface (both Trees and Grids).
When the file does not exist ( true fake component ), the document is now fully highlighted with the fake component background color:
In the above example, the document fakeTest01 is a BOM Item document of type PART, with no existing file,
while the document Master Cylinder Clamp Screw is a real assembly component, with only the BOM quantity being altered.
Customization of more result lists
By editing the Tables2.DFL file is now possible to customize:
- the list of fields for the grid showing a Working Set
- the list of fields for the grid showing the result of a Search
- the list of fields for the grid showing the documents to be plotted
The keywords for each supported language are:
|FRENCH||Ensemble de travail.||Search||Tracer|
|ITALIAN||Gruppo documenti di lavoro ||Ricerca||Plotta|
|SPANISH||Grupo de elementos seleccionados||Buscar||Plotear|
Blanks are replaced with the underscore character '_'.
Rules and Limitations:
- The Working Set and Search lists must contain the mandatory fields for accessing the basic informations of the documents, that is:
COMPANY_ID ( if the Remote Access is enabled )
SHEET_FORMAT ( for supporting the documents of type DRAWING )
The Working Set assignment can't be used when the Browser is opened in Update mode, for avoiding problems with the underlying ODBC record set
Extra PARENT_CHILD fields management
Editing for PARENT_CHILD fields has been enhanced; the standard input grid control has been applied to the PARENT_CHILD input form; this allows any <parent_child_added_field>.LST to be defined, such as for the DOCUMENT table;
in the example below, a PARENT_CHILD_MYFIELD1.LST has been created, with the list shown in the picture.
.VBSCRIPT and .SQL type .LST files are allowed as well.
The following is an example of .VBSCRIPT, related to the above fields, that allows you to automatically fill parent_child_myfield1 field when assigning the parent_child_bom_pos value.
File name: LST\parent_child_bom_pos.LST
bomPos = InputBox("Please assign the Parent-Child BOM Position Number:")
if bomPos<>"" then
DBWOutput "PARENT_CHILD_MYFIELD1","Value inserted automatically",ForAppending
Save/Load of current Browser's splitter positions
Two buttons in the Layout short-cut side bar are now available to save or load the splitters state in the Browser
API support for these two buttons is provided through these new shell commands:
RMB for Project Root
the Option "Show Selected Projects Only" should only appears if I selected a project, but not if I selected the "Project Tree" Root
Drag&Drop allowed independently from the option
User Interface®Trees®Enable Drag&Drop on Assemblies
Grids: default ORDER BY field
Added to open the browser and have the Grids ordered by default for a field different from the ID, suppose, by DESCRIPTION
Always Open Browser in Tree Page
option in the User Options section of the Options. This would give to each user the flexibility to work with the preferred page [Document vs. Tree] by default.
Unicode secondary language support
DBWorks/DBInventor can now manage an additional language (Unicode Secondary Language) in Unicode format (Chinese, Japanese, etc.)
The Unicode Secondary Language is used for displaying in Unicode format most of User Interface elements like:
- displaying Menus
- displaying Dialog Texts
- displaying Messages
- writing Variant Notes
- writing File Properties
Unicode Secondary Language Options
The support is controlled by a set of options in the General Options tab:
See options in details:
Enable Unicode Secondary Language
It is the main option to enable the Secondary Language Support; it loads specific dictionaries on memory.
DBWorks/DBInventor will look for specific files into the sub-folder LANG\UNICODE.
These files are:
<Secondary Language Identifier>.UMSG
Specific messages file name are of the format <Secondary Language Identifier>.UMSG
Messages files are Unicode Text files, containing the dictionary of each User Interface element of DBWorks/DBInventor.
<Secondary Language Identifier>.UDBWUI
It is a Unicode Text file, containing the list of the UI_<field name> fields, exactly like the DBWUI.MSG file, used for the User Interface localization.
Display both Primary and Secondary languages
When checked, DBWorks/DBInventor will display both the Primary Language string and the Secondary Language string for each user interface element.
Manage only Variant Notes and File Properties mapping
When checked, DBWorks/DBInventor will use the Secondary Language support only for creating/updating the Variant Notes and File Properties; the User Interface elements will not be altered
Database structures needed
A new table named DBW_UNICODE_MAPPING_TABLE is necessary for mapping generic strings in the Primary Language to generic strings
in the Secondary Language.
The structure of the table is the following. Please note the NVARCHAR type of the SECONDARY_STRING,
needed since it is a UNICODE string.
Variant notes support
The special macro $SECONDARY() is supported by the variant notes, as wrapper of a standard variant note.
A mapping is then applied with the result of the query as executed with the Primary Language interface.
Suppose that the mapping table contains the three records:
Suppose now that you are inserting/updating a document in the database, with DESCRIPTION="Description number one".
Insert into your drawing a variant note as follows:
The variant note will be resolved against the Unicode Mapping table and displayed as:
File Properties support through the SCHEMA\BOMTITLE.TXT file
The special tag "UnicodeSecondaryLanguage@" is intercepted for mapping the content of the current property into its Unicode mapping found in the DBW_UNICODE_MAPPING_TABLE.
To understand the behavior, look at the following example of BOMTITLE.TXT:
; DBWorks (C)MechWorks BOM titles file
; Language: ENGLISH
Every time the Property DESCRIPTION will be written into the File Properties, DBWorks will look for a matching record in the DBW_UNICODE_MAPPING_TABLE, and, if found, it will create a new Property, whose name is assigned after the @ character, with the Unicode content.
With the above BOMTITLE.TXT example, suppose that the mapping table contains the three records:
Suppose now that you are inserting/updating a document in the database, with DESCRIPTION="Description number one".
Since DESCRIPTION is declared in the BOMTITLE.TXT, a mapping will be created.
DBWorks will look into the DBW_UNICODE_MAPPING_TABLE for a record where PRIMARY_STRING='Description number one' and SECONDARY_LANGUAGE='CHINESE', and it will find
The Property name, after the @, is 'DescrChinese', so the following File Property will be created:
In the About … dialog, insert a new button Check for Updates checks if any update of DBWorks/DBInventor is available for downloading
Use of the EVENT_LOG::DOCUMENT_DELETED information
By using the information contained in the events DOCUMENT_DELETED of the table EVENT_LOG it will be possible to avoid ambiguities when exchanging database structures that may contain deleted parent-child relations. It also will improve the management of References documents, by removing data no more existing on the original sender company.
- company A sends a reference briefcase to company B
- company A deletes some records
- on next briefcase send, the briefcase system will transfer also the current EVENT_LOG::DOCUMENT_DELETED records and use it for deleting the foreign records on the database of company B
Parameters for the current Variant Note
It is now possible to define parameters for a single Variant Note. The list of the parameters must be delimited by the @ character, like @DBW=@<list of parameters>@<variant note definition>
The available parameters are:
Wraps the text of the Variant Note to a maximum number of characters on a single line.
Suppose you have inserted the following variant note:
Suppose now that the field NOTES contains the following string:
This is a single line of text that has been added
to the notes field within DBWorks and it is an example of a long block of text that
will be displayed within the Drawings titleblock on multiple lines of text.
Since it is a very long string, when displayed in a drawing, it will appear as:
Now, let’s modify the Variant Note as follows:
The text will be wrapped with a limit of 20 characters per single line, and it will appear as follows:
Move of ProjectÛUsers and ProjectÛDocuments in the Administration Control Panel
The Projects Users Assignment interface has been redesigned for DBWorks 2006 to simplify the views and the interactions
ProjectÛUsers: support for Groups
Possibility to assign all users belonging to one group (like DBWorks Designer) to a project with one step instead of selecting all the users of that group manually.
Full Preview support for the Autodesk DWG TrueView
The proprietary Autodesk DWG TrueView viewer is now supported in the Full Preview Tree Page’s tab:
Assignment of the next revision value in the Multiple Checkout dialog
It is now possible to assign the next revision value directly from the Multiple Checkout dialog.
A new column Next Rev. can be filled with the next revision value by clicking it.
Dependently from the option Revisions®Use ONNEWREV.LST script for assigning a new revision name, DBWorks/DBInventor will invoke the script or will propose the default list box for assigning the next revision.
When invoked on the initial load of the form, the OnNewRev.LST script will receive the DBWInput("@MODELESS") set to 1, to indicate to the script that no message boxes or dialogs should be displayed, so proposing a default next value for the current revision.
When clicking on the next revision value proposed, DBWorks/DBInventor will invoke again the script with the parameter DBWInput("@MODELESS") set to 0, to indicate to the script that now a full interaction is allowed.
Please note the Next Rev. value of B. Please also note that for the unchecked components, no automatic calculation is performed, until they will be selected.
Now, without any script, when clicking on the Next Rev. B of the first row, DBWorks will propose the default list for the next revisions:
If the OnNewRev.LST is activated, it will lauch it when clicking on the Next Rev. value:
Please note that the revisions manually assigned are marked with a RED color.
Automatic uncheckout/uncheckin of unmodified checked-out components
A new option is available: Revisions®Approval® Undo the checkout when no changes in the documents on a recursive approve
When checked ( default is not checked ), DBWorks/DBInventor will automatically uncheckout-uncheckin the assembly components that have not been modified while editing the assembly.
In this way, it is possible to checkout the whole assembly ( by creating a new revision for each component ), and to avoid unnecessary revisions for unmodified components to be approved.
The approval dialog shows the components that have not been modified with a darker color, and with the revision value displayed in a green color, to indicate that no revision increment will be applied.
In the picture, the component 27380ref7 has been modified, and since it belongs to the sub-assembly 27380, that in turns belongs to the assembly 27511, only three documents will be approved in the next revision; all the others, displayed with a darker color, will be rolled back to the original revision, since of no changes.
New script: OnShowPreviewLabel
By using this script it is possible to customize the text that is displayed in the label of the Preview window of a document:
The purpose of this script is to provide a visual feedback on the intermediate releases of a document, and on any useful information that may help to better understand the correct state of a document.
This is an example of a label modified by customizing the script
Always use Excel_BOM for the Buy List
A new option is available: General®More® Always use Excel_BOM for the Buy List
When checked, the standard BuyList procedure will always be replaced by the Excel_BOM procedure.
- when pressing the $ button in the Tree Page
- when building the BOM of a previous Revision, from the Revisions Input Form
- when invoking the DBWShell(“BuyList”) command
"Create a New Bom Item" command available also for Generic Documents
The RMB®Create a New BOM Item command is now available also for Generic Documents, allowing the creation of child Generic Documents for BOM purposes.
Please note: by default, any new BOM Item of type Generic is marked with MAKE_BUY='MAKE', unless the MAKE_BUY attribute is explicitly changed by the user.
Administrative tool for managing Group/User specific DBWAPP.PARs
If the currently logged in user is a DBWArm Administrator, a EDIT... button is available in the options page if the option
Environment®DBWArm Use DBWArm Group Specific Parameters is checked:
The system shows the list of directories available for each DBWArm Group; the DBWArm Admin can then access the proper directory for which he intends to edit options, and open the specific DBWAPP.PAR for that Group; a new Options editing dialog is then displayed, with the title showing the particular group options being edited:
New option: Never share my own created projects
If the new option
Environment®DBWArm® Never share my own created projects
is checked, the Project tree will display:
- any project with the _SHARE attribute explicitly set
- any project created by a DBWorks Admin personality
- any project where the CREATED_BY is the currently logged in user
For the _SHARED and “DBWorks Admin Owned” projects, there will be applied any ProjectÛUsers assignment eventually defined
New right : Deny Previous Revision Approval
The purpose of the new right in DBWARM settings
DBWARM rights®Deny Previous Revision Approval
is to allow only selected people ( like Admins ) to approve on a previous revision, normally for fixing approval mistakes
Change PIN on next Login
Ability to have an Admin set the Pin for each of the users but then force the Users to change that pin to something else
New sub-option: Drawing extensions to be managed
|Plot Setup®Plot only drawings|
|Drawing extensions to be managed|
It may be useful for mixing actual CAD drawings ( like .SLDDRW ) with legacy drawings ( like .DWG, .MI, etc ).
The plotting engine will properly invoke the OnPlotG.LST for any legacy drawing to be plotted.
By using this option it is possible to create a Working Set of mixed actual drawings and legacy drawings, and launch the plotting process. More, the DBWShell(“Plotall
”) command will accept a list file containing both actual and legacy drawings
DWG MI IDW
Differentiate commonly named fields between the DOCUMENT and REVISIONS tables
It is now possible to differentiate the .LST files and the DBWUI.MSG strings for any field name in common between the DOCUMENT and the REVISIONS table
.LST files specific for the REVISIONS table
DBWorks/DBInventor looks now for a file named REVISIONS.<field name>.LST, and if existing, it loads it for populating the combo box of a field in the database Input Form.
The table name REVISIONS is localized for each supported language.
DBWUI.MSG strings specific for the REVISIONS table
DBWorks/DBInventor applies to the REVISIONS table any entry of the DBWUI.MSG that has the following format:
If it does not exist, it applies the default rules.
UI_REVISIONS.NAME_FIELD_DESCRIPTION "EC Desc."
UI_NAME_FIELD_FILE_NAME "File N."
Multiple sub-classes of Data Input Forms
It is now possible to define more than one level of Sub-classes for the Data Input Form.
Suppose you need to have different forms like in the following example:
This will be possible with the following Dataentr2.txt extensions ( CATEGORY1 contains the main family BEARINGS, while CATEGORY2 contains the sub-family INTERNAL or EXTERNAL ) :
File being processed:
Files being processed:
Assumptions and rules
- Every level must refer to a different database field ( ex: level 1 Û CATEGORY1 , level 2 Û CATEGORY 2, ... )
- The @SUBCLASS must explicitily contain all the hierarchy ( that is like @SUBCLASS_BEARINGS_INTERNAL, not correct would be @SUBCLASS_INTERNAL )
Sub-classes allowed in the Revisions Data Input Form
It is now possible to define more than one level of Sub-classes for the Revision Data Input Form.
The rules and syntax are the same as for the DataEntr2.TXT case.
Remember last FILTER settings
Possibility to have the LAST used filter settings ( Yellow filter button ) in an individual’s account be held for the current session
Link mode on attached Generic Documents
New options for managing also the attachments of Generic Documents ( descendants to the main documents ):
Environment®Link Mode® Manage Child Generic Documents
SQL filter condition:
Filter with the SQL syntax for discarding/accepting relations with descendent generic documents
FILE_NAME LIKE '%.DOC' OR FILE_NAME LIKE '%.XLS' AND NOT ID LIKE '123*'
New option for Saving As any linked Drawing
Environment®Link Mode® Always 'Save As' all the linked Drawings
At every 'Save As' of a Part/Assembly, DBWorks/DBInventor will look if any linked Drawing is existing, and if so, it will Save As the drawing as well, replacing the references in the new drawing with the new document just saved.
Improved Link Mode consistency
Environment®Link Mode® Include linked documents when deleting
This option will automatically include any linked document in the Selection Dialog of the Delete functionality
Environment®Link Mode® Include linked documents when assigning/changing the Project
This option will automatically include any linked document when a document is moved under a different project, or included into a new one; in particular:
- RMB®Projects®Add To/Remove From Project: any linked drawing, configured brother or derived part is added/removed as well
- Drag&Drop on a Project: any linked drawing, configured brother or derived part is added to the target project, detaching it from the old project if the CTRL key is kept pressed while dragging
- ProjectsÛDocuments Management: any linked drawing, configured brother or derived part is managed as well
- Save of a document when the Option Projects® Avoid automatic parent document project assignment is unchecked: any linked drawing of the child components is inserted in the current project as well
Script for managing the file transfers between the remote and the local site
The new script OnRemoteAccessFileTransfer.LST can now be executed whenever a remote file transfer is needed.
It can be enabled through the option Environment®Remote Access® Use OnRemoteAccessFileTransfer.LST script
The script is executed every time a file transfer from the remote site to the local site is needed by DBWorks/DBInventor.
Not only the main document files, but also the .GZ or .JPG files must be managed by this script.
Improved synchronization of foreign local copies of documents
A new option is now available for maintaning updated any downloaded foreign document that will be opened by the designer:
Environment®Remote Access® Always Refresh Documents Local Copies on Open
The refresh operation applies to the currently opened document and to all its children documents.
Tree-type commands available also from the Grid’s RMB popup menu
The following commands are now available also from any Grid’s RMB popup menu:
- RMB®Download the Remote Component and all the children
- RMB®Refresh Remote Components for the node and all the children
- RMB®Delete the Local Copy of the Remote Component and all the children
- RMB®Take Ownership of the node and all the children
Working on Local Drives by using the Remote Access support
This feature permits to work locally on large assemblies; local means that files will be downloaded/uploaded via the LAN from/to a main central server.
The main global option for enabling this modality is
Environment®Remote Access® Enable Local Mode
Please note it is a sub-option of
Environment®Remote Access® Use Multiple Network Drives
because the Local Mode needs to know the name of the Network Drives currently used for accessing the files in the shared archive.
As a consequence of the above statements, Local Mode has some limitations:
- The Local Mode does NOT support databases where the FILE_DIRECTORY field is populated with a UNC path
- The Local Mode must have the file archive’s Network Drives different from the Network Drives used for the GlobalParametersPath shared installation files; if this limitation may cause problems for the IT Administrators, as a workaround, the GlobalParametersPath and any directory parameter in the DBWAPP.PAR itself ( like the LST_DIR, PAR_DIR, SCHEMA_DIR, SQL_DIR, USERS_DIR, XLS_DIR ) may be set with an UNC path ( like \\MyServer\MyShare )
Environment®Remote Access®Local Root Directory
Contains the Local Drive directory, there DBWorks/DBInventor will rebuild the file structure of the main shared archive.
Environment®Remote Access® Release Local Ownership on Checkin
When checked, it forces the release of the Local Ownership at Checkin time.
The Local Ownership is always released at Approve time.
User Options®Remote Access® Work Locally
Since it is a User option, it is ALWAYS exposed to each user, no matter about the DBWArm permissions on the full options editing.
How it works
DBWorks/DBInventor switches dynamically the Network Drives declared in the DBW_COMPANY_INFO table, assigning them to Local Drives or to Network Shares depending from the state of the Local Mode user option.
The designer will normally work in the Shared environment, until he will need, for performance reasons, to work locally on his workstation.
The local files are synchronized with the shared files:
- whenever a reference document is opened; if it is an assembly, the whole child structure is checked and synchronized if necessary
- whenever a RELOAD message is received from any other workstation
The user can always force a manual synchronization with the RMB®Remote Access®Refresh local copies command.
Suppose the designer wants to work locally on the shared Handlebar Complete assembly; for this example, the assembly is considered in the Released state:
The Environment®Remote Access parameters are set as follows:
The designer opens the User Options and checks the option
By clicking OK in the Options, DBWorks/DBInventor will re-assign the Network Drives declared in the DBW_COMPANY_INFO to the Local Drive; for this example we will use only ONE Network Drive, named O:
Before hitting OK, the O: drive was assigned to \\server1\E, after the OK the O: drive is now assigned to E:\TEST\LocalMode\, with a SUBST Windows Shell command.
- The Tree is now displayed as follows:
Each item is now displayed with a lighter color, and striked-out. The convention used is:
- lighter color: the document is not OWNED by the designer, and it is still shared to everyone
- strike-out: the document file is NOT existing on the local Workstation, and needs to be downloaded
The designer wants now to work locally on the sub-assembly Throttle Temp, but he needs to have locally the whole main assembly Handle Bar Complete; so, it downloads locally the Handle Bar Complete assembly, by selecting it and using the functionality
RMB®Remote Access®Download the Remote Component and all the children:
The main assembly is now available locally, under the E:\TEST\LocalDrive\O\ location ( DBWorks creates a sub-directory for each Network Drive declared in the DBW_COMPANY_INFO table ), mapped as O: ; the Tree appearance changes as:
The items are no more striked-out since their files now exist locally.
The designer can now CHECK-OUT the sub-assembly on which he wants to work:
After clicking the OK, the documents are now fully owned by the designer, and the owned items are now displayed normally:
In the above picture, please note that for the owned items, the Company_Id has been now internally changed to <designer id>@<main company id>, and that the Owner_company_id in the database has been assigned to <main company id> to indicate that the items are TEMPORARILY owned by a designer, since he is working locally on them.
When finished working on the sub-assembly, it can be CHECKED-IN or APPROVED with the Multiple Approval functionality; lets say we will now do a CHECK-IN on it:
After clicking OK, the documents are no more exclusively owned by the designer: their ownership has been RELEASED:
The documents in CHECK-IN state are now displayed again with a lighter color, to indicate that any operation on them can now be undertaken on the shared archive
Suppose now that the designer has finished to work locally; before switching to the Shared Mode, if he likes and if he needs to clean up some free space on his hard disks, he can delete the Local Copies with the proper Remote Access command:
He is now ready to switch back to shared mode by unchecking the User Option:
DBWorks/DBInventor will now re-attach the O: drive to the Share \\Server1\E as declared in the DBW_COMPANY_INFO table; this allows to work back on the shared folders.
The appearance of the Tree now has no more light items, since all the items are now shared:
If the Workflow module is available, the designer can now submit the modified sub-assembly to the workflow, for its definitive approval:
Working on Local Drives by using the Local Checkout Mode support
This feature will permit to work locally on large assemblies while continuing to use the Local Checkout Mode.
A new folder, named Local Read-Only Folder, will be inserted in the SolidWorks External References File Locations list, between the Local Checkout and the Shared Checkin folders:
SW File Locations for External References:
<Local Checkout Folder>
<Local Read-Only Folder>
DBWorks will keep synchronized the folder at checkout/checkin/refresh.
DBWorks will visually mark the documents that have a copy in the Local Read-Only Folder.
A tool will assist in managing ( adding/removing ) files from the Local Read-Only Folder.
ECR separated by ECO
To date it may be too restrictive in the fact that it forces an ECR to exist before any user can [Increment the Revision] of an existing record. It is our belief that this option needs a related sub-Option similar in nature to the existing [Use OnCheckIfMajor Revision.lst] option. Is it possible to add the following sub-option:
This would allow an organization to customize the above script to incorporate GROUPS/USERS/REVISIONS that could bypass (using filters) the forced existence of an ECR. I believe that most organizations will need to allow the default engineering groups to always be allowed to create new revisions, regardless if an existing ECR already exists.
New option for saving a Drawing always in the Project of the document
By checking the new option
Projects® Save drawings on the Part/Assembly's project when saving a drawing
DBWorks/DBInventor will assign it to the project of the first referenced model in the drawing.
Comparison of Project structures at different revisions
When both the options
Revisions®Approval® Create structure history for all the Document types
Projects® Enable revisions for projects are checked, DBWorks/DBinventor creates now a .TREE file representing the Project structure in the shared XLS folder ( assigned in General®Path®Project XLS output directory (.XLS) ).
The presence of the .TREE files allows the comparison of two Project structures at different revisions.
Log errors on file
Added the ability to report the errors to a DBWLM logfile rather than using screen output, for better instpecting the errors when DBWLM is started as a service