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
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)]