I added a new date field, cstReminderDateDA, to a custom business object. For existing records, there is a requirement that cstReminderDate be set to the value of an existing date field (cstDueDateDA) minus 30 days, i.e. cstReminderDateDA = (cstDueDateDA – 30). This would be pretty straightforward, except that both cstReminderDateDA and cstDueDateDA are stored as numeric fields in our Microsoft SQL Server database. How do I populate cstReminderDateDA?
IBM TRIRIGA stores the date as epoch time. See the following wiki link explaining this. If you do some searching, you will find some functions available for SQL Server for data calculations.
[Admin: To see other related posts, use the Epoch Time tag.]
I am attempting a clean install of TRIRIGA 3.5.3 and according to the logs, it appears that the installation was successful within the was-ant.log. But I receive this error in the ant.log… When I access the application, I was unable to pull up the login page. Checking the server logs, I noticed these errors… The odd thing is that when I did a TRIRIGA 3.5.3 install on WebSphere Liberty, it worked perfectly…
The errors seem to indicate that you selected an upgrade, not a new install. Are you sure you selected a new install? Some of the environment properties that are needed to start up do not seem to be available. Did the database get created or are you pointing at an existing database? What happens if you do a select * from environment_properties on the database you are using?
The DB2 exception you are receiving seems to indicate you are running out of statement handles, but it’s hard to see this happen with a successful install.
[Admin: To see other related posts, use the WebSphere tag or “install error” search phrase.]
I made a big import of data in TRIRIGA, but the resources were not enough to proceed. So I have to stop TRIRIGA and truncate all events to stop the import. But now, the database log never stops growing and crashing the database. Is there a way to clean up and make TRIRIGA stable?
If this is Microsoft SQL Server, this may be related to the following SQL Server defect: SQL Server crashes when the log file of tempdb database is full in SQL Server 2012 or SQL Server 2014.
[Admin: To see other related posts, use the SQL tag or “sql server” search phrase.]
Is AutoCAD LT compatible with CAD Integrator functionality?
No, it’s not compatible. See the compatibility matrix for IBM TRIRIGA CAD Integrator/Publisher. At the bottom, the comments provide more details.
For example: “My understanding is that the CAD Integrator does not work with the LT versions of AutoCAD because LT versions do not support database connectivity and cannot use programming tools such as VBS, LISP and ObjectARX.”
[Admin: To see other related posts, use the Integrator tag or AutoCAD tag.]
We are seeing an Oracle error during OM package import related to the number of open cursors. We checked the documentation, but there is no recommendation of what the cursor size should be for large OM package imports. We are currently on 500. Has anyone seen this issue or performed a successful upgrade in this regard? What is the optimal cursor size being used by different clients?
I checked with one of the senior TRIRIGA architects, and he said he would recommend setting open_cursors to at least 2000 for an OM package import. I hope this information helps!
[Admin: To see other related posts, use the Object Migration tag or Upgrade tag.]
I wanted to see if anyone has set up the following settings in an Oracle Database for TRIRIGA 10.5.2 and 3.5.2:
- 1. NLS_LENGTH_SEMANTICS: Should this be set to CHAR? In our current production environment, it’s set to BYTE, but the TRIRIGA support documentation says that this can lead to data loss, so they recommend using CHAR.
- 2. NLS_CHARACTERSET: This is set to WE8ISO8859P1 in our current production environment, but the support document says that it must be UTF-8 or UTF-16.
- 3. Block size: This is set to 8k, but the documentation recommends using 16k.
For (1) and (2), if you never want to store multibyte characters, then what you have is fine. But if you do, then you must use what the support documentation suggests. Once you have your database created, it is difficult and time-consuming to change it, and it needs to be done outside of TRIRIGA. As for (3), I would encourage you to use 16k, since it will allow you better throughput and paging, unless you have a strong reason why you need to stay at 8k.
[Admin: This post is related to the 04.04.16 post about database character settings. NLS refers to National Language Support parameters in Oracle. To see other related posts, use the Multibyte tag, MBCS tag, or NLS tag.]
We have an issue with duplicate opportunity rows in the building’s Assessment tab. The issue seems tied to the building system class smart section and the underlying table reporting against it, T_TR_DEF_LI_IT_TR_BUI_SY_CL, while in a building record, Assessment tab, when we create a new opportunity, fill in the building system class smart section (not the building system item one), and create draft.
If a user then tries to change the building system class, but then decides to not save and instead just closes the form, the row that is entered into the table T_TR_DEF_LI_IT_TR_BUI_SY_CL for the temp data, is not removed when the record is closed without saving. Which results in the opportunity query on buildings displaying the opportunity twice. This seems to be a general issue with the use of these tables, since it also happens when you do the same steps on a work task and a facility project; an extra row remains in T_TR_WO_TA_TR_FACILIT_PROJ.
Has anyone else encountered this issue and found a way to correct it? Using the steps below, can anyone confirm that the issue happens for them as well?
This issue is being addressed through PMR 12839,082,000 / APAR [IJ00504].
[Admin: To see other related posts, use the Assessment tag.]