Our customer has seen an issue when installing TRIRIGA 3.5.3 (Linux, Server build number: 276955) on an existing database (on 3.4.2 / 10.4.2). Everything goes well until starting up the server. Generally, TRIRIGA will run a database upgrade on the first startup when a build number difference is detected.
In the OM log, we notice that TRIRIGA tried to import the upgrade OM package… The import process started with the triPlatformObjectLabelManager package, but it failed to import a navigation item, which is newly created for Object Label Manager. I haven’t found any log which can explain this failure. I’ve checked the NAV_ITEM table. This navigation item wasn’t there before the upgrade process. Then all of the other packages are stuck on a pending status. Nothing happens after “Creating package from Zip file”. This behavior causes a lot of SQL update failures.
Meanwhile, on our Dev environment (Windows, Server build number: 279835), the upgrade went very well. You can find the difference in the logs. The OM log was set on “Debug” level on both servers. Note that the build number is slightly different between these two enviroments. Have you seen this kind of issue? Where can I find more details about the navigation item import failure?
[Admin: This post is related to the 02.17.17 post and 05.19.16 post about inconsistent OM validation results. To see other related posts, use the Object Migration tag or Upgrade tag.]
I’ve made some modifications to a handful of forms that are connected to CAD BO Mapping records (e.g. triEmployee, triSpace, triFloor, etc.). I’ve updated the label to follow the traditional TRIRIGA customization standards and relabeled them with “cst” such as “cst-triSpace”. However, in AutoCAD, when I attempt to Smart Attach and/or Publish drawings, I get an error that seems to point towards the GUI Name of the form not lining up to the CAD Mapping. How do I get CAD Integrator to pick up the same form but with a different label?
When renaming those forms, you must make a few changes to the CAD backend:
- 1. Create new CAD Mapping records that point to the new form. I recommend checking the old mapping records to make sure all fields are added properly.
- 2. If you added any required fields, I believe that they need to be added to the CAD Mapping record.
- 3. Open the CAD Hierarchy and make sure each node is pointing to the new Mapping record that you created from Step 1.
- 4. Update the form on the CAD Label Style to point to the new form.
Note: If you are on a newer platform, I recommend keeping the form names as “tri”, and using object labels to manage versioning.
[Admin: To see other related posts, use the Integrator tag or Object Label tag.]
We are working on CAD integrator (for AutoCAD) and we are wondering if it is possible to generate labels for spaces (based on label style) on different layers of the floor plan. For example, displaying the name and area on triLabelLayer and space class on triClassLayer. Actually, it seems that all the labels are created on the triLabelLayer. Is it possible to customize to allow multiple layers for labels?
I reviewed this with the developer. It would be a request for enhancement (RFE).
[Admin: To see other related posts, use the Integrator tag.]
Is there a way to query which label class is being used on which fields? I want to tweak the existing ones slightly, but I’m not sure what is going to be updated when I make the change.
[Admin: To see other related posts, use the Labels tag or Query tag.]
We manage properties globally so some of our locations are measured in Imperial and some are in Metric. What is the best way to manage this type of scenario so that our drawing and graphics section labels are not incorrectly sized when they are viewed from other global geographies?
The best way to address this situation is to have 2 sets of labels for your drawings, and 2 sets of labels for your TRIRIGA graphics section. You will need to adjust the height of the label elements to work for both situations. We are considering an enhancement to automatically scale according to the drawing units.
[Admin: To see other related posts, use the Graphics tag or the Labels tag.]
The pie chart labels should actually be hidden, and not appear at all for the smallest portal section. Users should rely on tooltips for the smallest portal section. The reason labels were always meant to be hidden is because they make many pie charts unusable in the smallest portal section, due to labels bunching together in the small space. The smallest portal section should always hide the pie chart labels.
The hiding of the pie labels for the smallest portal section broke when AnyChart was upgraded in TRIRIGA 3.5.0. Moving forward, we resolved a metric report and chart report issue, where pie chart labels were chopped off in the smallest portal section. This fix hides pie chart labels when the TRIRIGA component that displays the chart falls below a height of 280px and a width of 280px, such as the smallest portal section. Pie labels become unusable when pie charts get too small. So users should rely on pie chart tooltips for the chart details, when the labels are hidden.
[Admin: This post is related to the 04.14.16 post about changing the AnyChart label settings. To see other related posts, search “Pie Chart“.]
I have been trying to do an object migration (OM) import, but I am getting a validation error on one of the navigation collections contained in the OM package. It is not an error I have seen before, so I wondered if anyone could tell me what it meant? And how I can resolve it?
Which TRIRIGA Platform version are you using? I know we fixed an issue related to OM packages in our TRIRIGA 3.5.2 release, where certain navigation items were not exporting correctly, which may be related to you having problems importing the object. The following is the text from the TRIRIGA 3.5.2 release notes:
“Resolved object migration issues where Navigation Items may not export correctly if the Dynamic Label check box was selected and the Dynamic Label Query was not selected on the Navigation Item definition. (Tri-250723)”
[Admin: This post is related to the 05.19.16 post about inconsistent OM validation results. To see other related posts, use the Object Migration tag.]