In a standard OOB installation of TRIRIGA on Windows Server 2012 R2, it gives the user group the “Execute” and “Special” permissions to the TRIRIGA folder. We are concerned from a security perspective: Why are the “Execute” and “Special” permissions needed for a standard installation? What are the minimum permissions needed for TRIRIGA to function correctly?
You can remove the user group “Execute” permission on Windows. Only the service user needs permissions to read from the install directory, and/or execute WebSphere Liberty under the TRIRIGA install directory (if so installed).
[Admin: To see other related posts, use the Permission tag or Security tag.]
When you try to run one of TRIRIGA’s Application Platform or CAD Integrator installers, most often on a Windows 10 or similar machine, the following InstallAnywhere-based “LaunchAnywhere” error may occur:
“Windows error 2 occured while loading the Java VM.”
This is an issue, not with running the TRIRIGA installers on a Windows 10 machines, but with Flexera InstallAnywhere found within TRIRIGA installers having difficulty parsing the version as it is listed in Java 8 Update 60 and higher. The specific problem being encountered is described here.
Determine if the installer that is running is using Java 8. If so, to determine if the version of Java 8 you are running is update 60 or higher, perform the following… If the version of Java 8 you are running is update 60 or higher, run the TRIRIGA platform or CAD Integrator/Publisher installer using the following command…
[Admin: To see other related posts, use the InstallAnywhere tag.]
Is anyone having issues publishing CAD drawings via IBM TRIRIGA Platform 3.5.2, CAD Integrator 12.1.6, and Windows 10 OS? The support compatibility matrix mentions support for IBM TRIRIGA 3.5.2 with Windows 10 OS, but it doesn’t specifically mention that CAD Integrator 12.1.6 is supported by Windows 10 OS.
IBM TRIRIGA CI 12.1.6 with Windows 10 OS is supported and should publish without issue.
[Admin: To see other related posts, use the Integrator tag.]
We are currently using TRIRIGA 10.5.1/188.8.131.52. In IE11, when a record is selected to print, the printer gives a blank page. Whereas before printing, selecting Print Preview shows the page correctly. This behavior was not observed with Google Chrome, where everything gets printed without any issues.
After further investigation, it looks like a Microsoft Windows Update broke this print functionality, and they have since reverted the change that broke it. If you are on the absolute latest IE11 patch, the Print Preview should be working again. Take a look at this blog link. Microsoft has released KB4032782 to address the issue.
[Admin: This post is related to the 11.07.16 post about the font in the Print Preview and printed hardcopy being too small. To see other related posts, use the Print tag or Print Preview tag.]
When exporting TRIRIGA records that contain text fields with carriage returns and line feeds, these fields will have extra spacing between the rows when viewed in the Excel spreadsheet.
The issue is that Excel treats CR+LF (\r\n\) as two separate line feeds. Some operating systems such as Windows use \r\n to represent a carriage return. The fix is to detect the existence of \r\n in a text string, and treat it as single line feed (\n) that Excel recognizes.
Moving forward, we resolved a query export-to-Excel issue, where each carriage return in an exported text field value was appearing in the Excel cell value as two new lines. The fix ensures that Excel cell values display each carriage return in a text field value as a single new line.
[Admin: To see other related posts, use the Excel tag.]
There may also be an issue where the menu does not load, unless you use the CUILOAD command directly to load the TrgaAcad_en.cuix directly from the install directory. Then, attempting to login results in a _TRGA_LOGIN Unknown command “TRGA_LOGIN” message. The cause of this issue is that the CAD Integrator/Publisher (CI) is not initializing correctly…
Assuming NETLOAD works, the main issue is that probably the CI installer does not have permission to update the registry. CI actually uses the JVM and the command line to update the registry, so on certain secure systems, it may not be allowed to update the registry as needed to tell AutoCAD to load CAD Integrator…
The main issue is a permission issue where the CI installer cannot update the Windows registry to enable automatic loading, which is outside the control of the CI installer. If the CI installer cannot update the registry, then see the workaround…
[Admin: To see other related posts, use the Integrator tag or AutoCAD tag.]
With TRIRIGA 184.108.40.206 and BIRT 4.3.1 on Windows Server 2012 R2, we see that the “Export Report” option in a BIRT report defaults to “PostScript”, whereas in the current TRIRIGA 220.127.116.11 production version, it is defaulted to “Excel”. We want this export report option to be defaulted to “Excel” in TRIRIGA 18.104.22.168 as well. Only after upgrading from 22.214.171.124 to 126.96.36.199, we are seeing this change.
The BIRT engine did not sort the export options by default. Moving forward, the list of format options when exporting a BIRT report are now in alphabetical order, with the default being Excel XLS.
[Admin: To see other related posts, use the Export tag or BIRT tag.]