During TRIRIGA install, what SQL GRANT statements are executed for the install to be successful? Are there specific object names that you can grant access to TRIDATA on those objects other than granting to PUBLIC?
Granting PUBLIC access to database objects goes against security policy. The problem is that you don’t know which objects TRIRIGA might need. You need to get specific object names so that you can potentially grant access to TRIDATA on those objects, rather than granting to PUBLIC.
You might have tried to revoke public access to a database object which caused an ERROR on com.tririga.architecture.security.dataaccess.AuthenticationDAO and caused TRIRIGA to freeze while restarting TRIRIGA.
The following SQL GRANT statements are executed during TRIRIGA install…
I am installing TRIRIGA 3.5.0/10.5.0 on my local machine with WebLogic and Oracle 12c. But I am getting the following error:
[java] Connecting to system@jdbc:oracle:thin:@localhost:1521:orcl
[java] Exception encountered! java.sql.SQLException: ORA-65048: error encountered when processing the current DDL statement in pluggable database PDBORCL
[java] ORA-00959: tablespace 'TRIDATA_DATA' does not exist...
Installing to a pluggable database (PDB) or container database (CDB) is not supported in TRIRIGA 3.5.0. To resolve this, you will need to use the 3.5.2 platform installer or higher. Here is the 3.5.2 release note:
Installation: The installation of TRIRIGA Platform now supports connecting to Oracle via Service Name. This will allow you to use a RAC URL, or PDB installations. The installer will prompt for connecting via the older SID, or the Service Name as a section choice. (Tri-213951)
[Admin: This post is related to the 07.07.16 post and 01.26.16 post about getting an Oracle 12c error during install.]
How can I revert back an IBM TRIRIGA upgrade? Is there any way to do so? I need to get prepared and revert my system to a previous state in a case where there were system problems after an IBM TRIRIGA upgrade.
There is no uninstaller or code to revert back or downgrade your current IBM TRIRIGA Application or Platform version to a previous version. You must keep a reliable and preferably offline backup of the database (cold backup), in case you need to revert to a previous version.
Important note: If you have any new user or agent transactions during the period since the backup, they will be lost when you rollback the database. Bottom line: To manually “revert” to previous IBM TRIRIGA version you must…
[Admin: This post is related to the 06.10.16 post about object labels and revisions.]
How do I point my TRIRIGA application to a new database server?
If you are changing database servers in your lower environments, the easiest way to point your TRIRIGA application to the new database server is to run a new install of TRIRIGA. You would just reference the new database during the install.
We will be scaling up to 70-100 separate TRIRIGA installations, so I would like to do scripted installations to decrease installation time and lower the risk of human error. Does anyone have experience scripting the installation fully or partially under Windows Server OS?
With console-based installations, it is possible to use a scripting language called Expect, an extension of Tcl. With this, you can script installations, and read from different sources (like property files) for the responses to the prompts in the installer.
Starting in TRIRIGA 3.5.1, a new BIRT engine was introduced with your TRIRIGA installation. This is BIRT engine version 4.6.0.
To customize or create new reports, as well to convert your old BIRT 4.3.1 reports, you need the same BIRT Designer version. This Designer runs on the Neon Eclipse platform and you can use your current Java 1.8 with it (in older designers, you needed a Java 1.6, 32-bit, to make it work). This new version is optimized for Mac (in older versions, a lot of manual steps were needed). Also, you can have it as an application now. For Windows, it remains a folder in the location of your choice.
Another often-raised topic is about “upgrading from 4.3.1 to 4.6.0”. The fact is you can have both installed in your machine. They are separate installations. The caveat here is that you cannot use the same workspace for 4.6.0, if you already have 4.3.1 installed, so you just need to rename the workspace used for the first time.
So let’s start with what you need…
[Admin: This post is related to the 08.19.16 post about failing to connect with 3.5.1, and the 08.18.16 post about getting an HTTP Error 500.]
If you attempt to install the Reserve Outlook add-in into a folder within C:\Program Files\… the information provided on the command line such as URL is NOT copied into the user’s outlook.properties file. However, if you select any other folder in the computer as an install location, then the details are updated into the outlook.properties file.
The problem with using any other location is that those locations are not trusted by Windows. As such, the application when invoked forces a popup which, due to the expired application signing certificate, is not pretty. This is quite scary and is likely to result in many of the users declining the installation.
Because the files are sent to the users’ computers silently, they will not be aware that the add-in has been deployed into their machine. Any popup around email is worrying, so it is easy to see people taking the Don’t Install option.