We understand that sometimes with new TRIRIGA platform and application version releases, a new version of Crystal Server will be required (tested by IBM and supported) in order for our existing Crystal Reports to function. Deviation from the tested and supported version of Crystal Server identified in the compatibility matrix is considered to be a significant risk.
From what we have been told, the version of TRIRIGA is tightly coupled with the supported version of Crystal Server.We are looking for a better understanding of how clients who may be using a shared Crystal Server across their enterprise handles upgrades to the TRIRIGA platform. Because our business recommended the use of their enterprise Crystal Server with our existing TRIRIGA application, we would like to understand the issues and risks of going with using a shared server where the upgrade schedule (annually) differs from our TRIRIGA upgrade schedules (2 years for platform, 5 years for combined application/platform).
Are there other clients of IBM who use a shared enterprise Crystal Server? When they want to upgrade TRIRIGA, do they always have the appropriate supported Crystal Server version paired with TRIRIGA? If not, what are other accepted (if risky) solutions? Potentially, if we went with the enterprise Crystal Server, it would likely often be further ahead than the version recommended by our platform.
[Admin: To see other related posts, use the Crystal tag.]
In TRIRIGA 126.96.36.199, the user’s session was terminated by the server due to a missing security token on the request when interacting with forms and large queries.
We needed to add a TRIRIGA security token to two locations in the reporting engine. Moving forward, we resolved an issue that could cause a user’s session to be terminated if the user interacts with an editable query before the query has finished loading.
[Admin: To see other related posts, use the Tokens tag or Editable tag.]
We would like to use hatch patterns instead of solid fills in our graphics. There is a TRIRIGA wiki page “Graphics Section Hatching” that outlines how this can be done, but it isn’t working.
We needed to perform a server-only change. We needed to verify the uploaded image files in the CI hatch pattern record, and see the pattern rendered in the graphics section. Moving forward, we resolved an issue where assigning hatch records to the record results in the graphics section reports did not actually render the hatch images as expected.
[Admin: This post is related to the 06.03.15 post about displaying hatch patterns in graphics sections. To see other related posts, use the Hatch tag.]
After performing a TRIRIGA platform upgrade, some of the floor plans are not visible in the forms. Why aren’t they visible?
The TRIRIGA server cache needs to be refreshed. In other words, you need to clear the caches and restart the server. Here are more-detailed steps to clear your TRIRIGA cache and log folder:
- Login to the Admin Console.
- Go to the “Cache Manager” managed object.
- Click on the “All Caches (Global)” link and then “Hierarchy Tree Data – with rebuild” link. The process might take some time.
- Go to the “Database Manager” managed object, and click on the “Reprocess published drawings” link. Give the process some time to finish. Go to the current server log, and look for a related entry saying that the reprocess published drawing actions are finished. You will find a message similar to the following:
“INFO [com.tririga.platform.graphics.vector.drawing.DrawingService](http-0.0.0.0-21001-7) Finished re-processing drawings”
- Logout of the Admin Console.
- Stop the TRIRIGA JVMs via the WebSphere Admin Console.
- Delete the logs in the <TRIRIGA install>/log folder that has server.log.
- Clear the WebSphere temporary cache folder.
- Restart the TRIRIGA JVMs via the WebSphere Admin Console.
[Admin: This post is related to the 07.15.16 post about floor plan graphics disappearing after an upgrade, and the 09.29.14 post about clearing the TRIRIGA application server cache area. To see other related posts, use the “floor plan” or “clear cache” search phrase.]
This wiki is meant to help you troubleshoot and provide a workaround for the following publish error in MicroStation. It has primarily been seen in Select Series 4, but could happen in earlier versions of MicroStation. When publishing, the publish will fail. When you look at the server log, if you see the following error, then this issue is involved (the ACDSDATA, in particular):
com.tririga.platform.error.PlatformRuntimeException: Error processing DXF - last line read: 23500. Error: com.tririga.platform.graphics.vector.dxf.processor.UnexpectedGroupDataException: DXF contained an unexpected section type: Group-code:2 Value:'ACDSDATA' Source line:23499...
This error occurs due to the way in which MicroStation creates its DXF file for publishing for TRIRIGA, depending on its settings. The fix below is used to update MicroStation’s DXF output options to output using the “2010/2011/2012” format…
[Admin: This post is related to the 10.20.16 post about CI failing to publish. To see other related posts, use the MicroStation tag.]
I am experiencing an error with a smart section that was working just a week ago. This smart section exists across various environments, but is now causing an error in the development environment. I have experimented with the following:
- Removing the smart section causes record to show properly.
- Association and reverse association are both set properly.
- Removing all fields from the smart section causes the record to show properly, but adding any one field results in an error again.
- I can move the smart section to another tab and the rest of the record shows properly, until I click on the tab with the smart section.
- I have already tried object migrating the business object and form from an environment that works.
In the server log, this is error that shows:
440 ERROR [com.tririga.platform.error.ErrorHandler](WebContainer : 16) Report handled exception: com.tririga.platform.gui.rendering.GuiRenderingException: Could not render Gui Component: GuiTabMetadataImpl[Name=triGeneral,ID=14,GUI=GuiMetadataImpl[Name=tdbREProjectAuction,ID=10048479]] for record: SmartObjectImpl[ID=SmartObjectId[ID=47510356,Business Object ID=10002876],Business Object=BoImpl[name=triREProject,id=10002876,module=ModuleImpl[name=triProject,id=19]]][MID-3549400938]...
[Admin: This post is related to the 05.25.17 post about a GUI rendering issue. To see other related posts, use the Smart Section tag.]
I am getting a strange error when I am trying to deploy to TRIRIGA with the WebSphere Application Server (WAS). TRIRIGA doesn’t come up and throws an exception. Interestingly, when I point a Liberty application on the same DB2 database, it works well. I have confirmed with my network team that this is not a network connectivity issue. Here are the error logs:
Caused by: org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is java.sql.SQLException: DB2 SQL Error: SQLCODE=-805, SQLSTATE=51002, SQLERRMC=NULLIDR1.SYSSH200 0X5359534C564C3031, DRIVER=4.18.60 DSRA0010E: SQL State = 51002, Error Code = -805...
Have you checked to see that both the Liberty server and the WAS server are actually using the exact same version of the DB2 driver (db2jcc4.jar)?
[Admin: To see other related posts, use the DB2 tag or JDBC tag.]