dbMASS 3.9 |
| This file documents the enhancements and problem fixes provided with dbMASS version 3.9. Please read to stay up to date on these developments. CONTENTS----------------------------------------------- Version / Published
------------------------------------------------- 3.90 / February 4, 2000------------------------------------------------- 3.91 / February 23, 2000------------------------------------------------- 3.92 / March 3, 2000------------------------------------------------- 3.93 / March 21, 20001. Spherical Segment Mass DistributionThe spherical segment shape was introduced in dbMASS v3.81, however, the handling of mass distributions of this shape was not implemented at that time. This version provides the complete implementation and now the spherical segment shapes can be used in mass distribution analysis. See the spherical segment discussion for further details. 2. Expanded NotesThe Notes Window has been expanded to support text data in excess of 1000 characters. Previously the limit was about 250 characters. To accommodate this increase a resize icon/button has been added to the top right corner of the window. The window is initially displayed in its smallest form; 4 rows of text. One click on the resize icon will resize the window to fully display the note text or increase the rows of text supported by 4, whichever is greater. Additional clicks on the resize icon/button will increase the window height by 4 rows. Adjustments in the window width are simultaneously made until the maximum width is achieved. 3. Find/Replace "Any" CriteriaThere has been some confusion about the use of the "any" button in the search criteria of the Find/Replace Window. Some changes have been made to clarify its meaning. Now the criteria more clearly specifies that "any" data will qualify. Also, a confirmation warning has been added that pops up before executing a "replace all" request when the "any" criteria is set. 4. Copying Between DatabasesNew Feature. A feature has been added that will initialize the entry and the entry location field data to the existing entry/location values when the transferred data does not include all of the fields. An example usage would be when you want to incorporate updates obtained from another database that does not have the same fields defined as the one you are working on. Previously, the updates would come across with no data defined for the entries and locations field data not transferred. Now, if the entry/location previously existed in the database prior to the transferred updates, the field data for those entries/locations is used. Another use of this feature is to bring in updates from another database but to ignore the data associated with a particular field. To make use of this feature all you need to do is change the name/description of the field prior to the transfer. Then elect to not transfer the field data you wish to ignore. Once the transfer is complete, change the field name/description back to its original form. Bug Fixes. A bug was uncovered in the copying of multiple configurations / effectivities of entries. Once an entry id was transferred to track a modified entry, all subsequent entries that shared that id where automatically transferred without checking to see whether the particular configuration / effectivity of that entry had been modified. Now each unique configuration / effectivity of the entry is first examined to see whether it had been modified. If not modified, it will not be transferred. This eliminates entry records that haven't been modified from requiring duplicate processing because they previously were being transferred. Of course, this is only an issue when the different configurations / effectivities of an entry were requested to be transferred in the first place. Previously, if the only modification that was made to an entry was its contingency assignment or a change to its note, the entry data would not be transferred if the record already existed. Another change, e.g., to the mass properties or field data, was required to flag that the entry data had changed. Once a change was detected all entry record data was transferred. Now contingency and note changes are detected and will cause the entry record data to be transferred. Another problem that was fixed concerned weight distributions. Weight distribution analysis definitions copied between databases were previously not properly maintaining the coordinate transformations used for defining bin orientations. Also, the "sort on" class field identifiers assigned to bins were not being transferred correctly. Both of these problems have been corrected. 5. Database Repair IssuesBug Fixes. The rebuild indices functionality for the entry records and the assembly relationship records was found to incorrectly clear the user defined entry fields, location fields and uncertainty data. This was a nasty bug that would only occur if direct (vs. indirect) index errors were detected and repaired. Direct index errors are uncommon but the consequences were major if repaired using the past versions. This problem has been fixed. Direct index errors, should they occur, can now be fully repaired without the loss of data. A couple of other conditions were identified that would later cause dependency shift errors. This error, should it occur, indicates that a database table was not properly aligned with another. When it occurs it is possible that some user defined data assignments could be lost. The database repair feature can now detect and repair this condition before any negative consequences are encountered. Restoring Data. A couple of new features have been added to the database repair process that will support the recovery of contingency assignments and location field data from a previously know good database. These features can be used to recover selective data from an older version of the same database rather than have to completely return to the state of the backup. Should you find a need to use this functionality, contact i.e.Solutions to discuss its usage. There have been a few instances were a database table had its header information corrupted. dbMASS now inspects the table header information to detect this problem. Whenever a database is opened it will now automatically detect and repair any problems in this area should they occur. 6. Display GlitchesPlacing other windows on top of a Display Window previously would sometimes result in flecks of color appearing on the top window(s). This display glitch has been fixed. 7. Out of Memory WarningThe reserve memory held to create new objects (windows) was increased to help ensure that the warning to close some windows will be displayed before running out of memory. This warning message allows you to close some windows and then try the operation again instead of being forced to terminate the application with an out of memory condition. A minor memory leak was also identified and eliminated. 8. Item Descriptions in ReportsReport layout defined reports can include the item details for parts when the report layout is a drawing tree based report. To include the item details the "sub-element" section must be turned on. When an entry field is added to the "sub-element" section of the report layout the item related data is offered as possible fields. The items are identified by their description so be sure to include this field. In the past when the description of the item was requested the report contained in its place the word "actual" or "percent." This problem has been fixed. The item descriptions can now be properly displayed in the reports. |
9. Spherical Segment Mass DistributionSome final refinements to the mass distribution of the spherical segment that were mistakenly left out of the last release have been added. 10. Detecting Corrupted File HeadersThe ability to detect database file header corruption has been enhanced to cover a broader range of potential corruption scenarios. Any problems detected are automatically repaired at the time the database is opened. |
11. MPEX Indentation ProblemsTwo problems with interpreting indentation levels in MPEX formatted data were identified and fixed. The first problem occurred when the depth exceeded nine levels deep. This limitation has been removed. The second problem concerned the detection and handling of the ellipsis (...) characters that Microsoft Office applications will substitute when three sequential periods are used. (See previous enhancement) Each occurrence of the ellipsis character was causing two leading characters of the Identifier to be dropped. This should no longer be a problem. 12. Copying Between Databases (cont.)A couple of problems with the processing of transferred entries between databases through the use of the database copy commands were identified and corrected. The first pertains to an error in the implementation of a fix introduced in item 4 above. When copying multiple configurations / effectivities of an entry there was a logic error uncovered that could occur. If the first entry for a particular id / description did not need to be transferred because no associated data for the entry had changed, however, a subsequent and different entry with the same id / description but different configuration / effectivity did change and need to be transferred, errors would occur. The new id / description record added to track the new entry was not being properly set. This condition would result in a strange id / description being used (including non-standard characters) that may or may not be based on the original. This condition could also result in an out of memory error which would terminate dbMASS. The second problem uncovered was with the handling of duplicate standard parts copied between databases. A duplicate standard part is identified when it already exists for the destination database but either the description or weight is different for the copy. The standard part id / description would be listed in the Duplicate Window when processed as it should. However, if one selected to either edit the original or the update, a Standard Part Window was opened with the correct weight for the entry but the id / description was not correct. This problem has been fixed. 13. Display UpdatesNormally, when changes are made in one window that affects the data displayed in another window, the database manager sends a message to the affected windows to update their displays. A scenario was uncovered in which the message from the database manager was not being properly handled and the message to update was not getting delivered. A vivid example of this problem could occur when a Part Window was opened for a part that gets deleted. The opened Part Window will automatically close for the deleted part when it discovers, via this update message, that it has been deleted. In most cases it would, but because of this particular problem sometimes it wouldn't. This condition could also leave a displayed entry's mass properties outdated by changes made in a different window or by background processing. The problem has been corrected. |