How do you run the MS SQL “SetVarcharColsToNumeric_MSSS.sql” and “SetVarcharColsToNumeric_MSSS_Publish_BO.sql” scripts after upgrading to TRIRIGA 126.96.36.199? According to the TRIRIGA 10.5.2 and 3.5.2 release notes:
- “There are two scripts for MS SQL, SetVarcharColsToNumeric_MSSS.sql and SetVarcharColsToNumeric_MSSS_Publish_BO.sql. Run SetVarcharColsToNumeric_MSSS.sql first. When it completes, run SetVarcharColsToNumeric_MSSS_Publish_BO.sql.”
- “Run the script PRIOR to installation of IBM TRIRIGA Application Platform version 3.5.0. NEVER run the script after upgrading to 3.5.0.”
Our application is 10.4 and platform is 188.8.131.52. How can the SQL script be applied to update the system fields with the sub-attribute type of CreatedDateTime to CreatedDateTime (Number) and ModifiedDateTime to ModifiedDateTime (Number)?
I found this technote on the minimum required database permissions for TRIRIGA:
Following are the minimum permissions.
Anything else is untested and unsupported.
ALTER USER $dbuser$ QUOTA UNLIMITED ON $data_tblspace$;
ALTER USER $dbuser$ QUOTA UNLIMITED ON $index_tblspace$;
GRANT ANALYZE ANY TO $dbuser$;
GRANT CREATE VIEW TO $dbuser$;
GRANT CREATE TABLE TO $dbuser$;
GRANT ALTER SESSION TO $dbuser$;
GRANT CREATE SESSION TO $dbuser$;
GRANT CREATE SYNONYM TO $dbuser$;
GRANT CREATE TRIGGER TO $dbuser$;
GRANT CREATE SEQUENCE TO $dbuser$;
GRANT CREATE PROCEDURE TO $dbuser$;
GRANT DROP PUBLIC SYNONYM TO $dbuser$;
GRANT CREATE PUBLIC SYNONYM TO $dbuser$;
GRANT CONNECT TO $dbuser$;
ALTER USER $dbuser$ DEFAULT ROLE CONNECT;
But the following permissions are restricted for our customer:
DROP PUBLIC SYNONYM
CREATE PUBLIC SYNONYM
Can you tell me if these permissions are only needed for installation? Or are they also required for runtime?
The IBM TRIRIGA product team does not test nor validate lower permissions than what is documented. All permissions granted to the user are required for the support of TRIRIGA, and removing permissions can lead to unexpected behavior, performance problems, and possibly data corruption.
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.