Print Page | Close Window

Form_TreeView_BOM

Printed From: Roger's Access Library
Category: Other Download Libraries
Forum Name: Tejpal, A.D.
Forum Description: A.D. Tejpal's Library
URL: www.rogersaccesslibrary.com/forum/forum_posts.asp?TID=545
Printed Date: 18 Oct 2017 at 9:11am


Topic: Form_TreeView_BOM
Posted By: A.D. Tejpal
Subject: Form_TreeView_BOM
Date Posted: 19 Jul 2010 at 4:34am

Form_TreeView_BOM

 
Updates:  
    30-Aug-2010: SQL mode incorporated - for extracting product chain.
    04-Mar-2012: Subroutine P_ExtractProductChainByCode in general module modified so as to identify base parts in first iteration itself.


Explanatory Notes

    This sample db demonstrates extraction of complete hierarchical chain of sub-assemblies and components for the selected item. The user can select the desired item either by selection via combo box or by using the navigation buttons on the master  subform at top left, bound to the master table T_PartMaster. Fields PartName and UnitPrice are available for user interaction (i.e. editing or new entry). UnitPrice is to be entered only for base parts (items which are not meant to have any child assemblies or components). There is no limit to the number of nested levels permitted. Two alternative modes for extraction of product chain are demonstrated, i.e. either via SQL or via code. 

    Traditional approach using SQL for extracting product chain is known to suffer from certain limitations as follows:
    (a) Fixed number of maximum nested levels permitted.
    (b) Inherent limitation of access in maximum number of table instances allowed in a query.
    (c) For heavily nested structure, the output can be quite unwieldy and clumsy - involving extra sets of columns for each nested level.
    (d) The output is in de-normalized form.

    Adoption of a novel technique in this sample db, involving cascaded execution of SQL, has not only overcome all the limitations mentioned in previous para, but also ensured normalized output, with no limit as to the number of nested levels permitted. This approach represents a major breakthrough and is expected to provide significant gain in performance for large data sets.

    For the selected item, complete hierarchical chain of sub-assemblies and components gets displayed in the lower subform at right. For base parts, total quantity as well as total price are also shown in respective columns. Summary information (like maximum nesting levels, number of distinct assemblies and base parts as well as total cost of base parts needed for the selected item) gets depicted in label caption at top of this subform. For convenient analysis, the user can select any of the following styles of display, via option group below this subform:
    (a) All parts (Complete hierarchical chain).
    (b) Assemblies only - arranged as per relevant nesting level.
    (c) Assemblies only - Straight.
    (d) Base parts only - arranged as per relevant nesting level.
    (e) Base parts only - Straight.

    Simultaneously, the hierarchical chain of sub-assemblies and components gets depicted as tree view. Total cost of base parts (i.e. items which have no child assemblies or components) also gets depicted at bottom of tree view. Contents of tree view remain in step with the latest selection (out of five listed above) in option group. 

    Also, there is two way synchronization between tree view and the lower subform at right. If the user selects any node in tree view, corresponding record in subform becomes the current record. Conversely, if the user navigates to any record in the subform, corresponding node in tree view assumes selected state. PartID of matching record in the subform gets highlighted in a manner  similar to the shade signifying selected node in treeview.

    As the user navigates through master subform at top left, the contents of tree view as well as the two subforms at right keep getting updated as per current selection (treating current PartID on master subform as the top item for which hierarchical chain is to be extracted). 

    The upper subform at right enables the user to build new assemblies or edit the contents of existing ones. The three editable fields are: ParentPartID, PartID and Qty. Depending upon user preference, as per selection in the option group below this subform, contents of junction table get displayed in one of the following styles:
    (a) Hide all nesting levels beyond the top one. This provides the least cluttered view.
    (b) For nesting levels other than the top one, show only the assemblies (keeping base parts hidden).
    (c) Show all items - assemblies as well as base parts (base parts are items which do not have any child assemblies or components).

    Certain features as listed below have been incorporated as a help towards proper data entry or editing in the above subform:
    (a) If no data has yet been entered, default value of ParentPartID gets set as per current PartID in master subform at top left.
    (b) RowSource for ParentPartID combo box grows progressively in such a manner as to ensure continuity of hierarchical chain.
    (c) PartID can be entered only if ParentPartID for the given record has already been entered.
    (d) RowSource for PartID remains such as to prevent circular dependencies.
    (e) On entry of PartID, a super check is conducted against resultant circular dependency - if any.
    (f) Duplicates of a given combination of PartID and ParentPartID are not allowed. If the user happens to make such an entry, a friendly message is provided and the combination is not accepted.

    Note:
    (a) In table T_PartMaster, PartID is the primary key. Junction table T_ProductKits as well as transit table T_ProductChain make use of composite primary key made up of PartID and ParentPartID. (Values for PartID as well as ParentPartID are both derived from PartID of table T_PartMaster).
    (b) The sample db is designed in such a manner as to suit both data types for PartID (i.e. number or text).
    (c) PartName of top item as per master subform at top left is highlighted in distinct color. PartName of all sub-assemblies (not base parts) in the two subforms at right is highlighted in another distinct color. Corresponding nodes in tree view are highlighted in matching color.
    (d) For fetching various types of totals pertaining to current product chain, a hidden subform bound to a totals query is used. This arrangement is considered more efficient than multiple computations via functions etc.
    (e) While extracting hierarchical chain of components into transit table T_ProductChain, the process gets terminated as soon as any circular dependency is detected. This avoids the need for arbitrary limit to the number of recursive cycles for guarding against such a situation (thus eliminating any redundant recursive cycle).

Version: Access 2000 file format.

References:
    DAO 3.6
    Microsoft Windows Common Controls 6 (SP 6) - (This is file MSCCOMCTL.ocx - normally in System 32 folder of Windows directory)

   [Special Note Of Thanks to Arthur Fuller, Drew Wutka, Jim Dettman, Rocky Smolin and Shamil Salakhetdinov  (mentioned in alphabetical order) for the valuable inputs kindly provided by them in AccessD discussion group (Database Advisors)]

DownLoad File >>:  http://www.rogersaccesslibrary.com/forum/uploads/37/Form_TreeView_BOM.zip -  



-------------
--

Email: mailto:adtejpal@gmail.com - adtejpal@gmail.com



Print Page | Close Window