During the upgrade process, there is a timeout error:
During the upgrade process, there is a timeout error:
You servers likely can't handle the queries being run against such a large data set. You shouldn't maintain this many rows in tciDBActivityLog as they don't really serve a purpose other than troubleshooting…
In respect to tciDBActivityLog, the first thing to understand is that there should be few, if any, rows in this table. Although it was originally added to log direct back-end changes for Support, it can…
We haven't had this issue but the discussion let me to review our tables.
tciDBActivityLog 100,361,472
tciMaintAuditLog 2,373,982
Minimum activity date from the dbactivity log is 11-20-2017.
Minimum sysdate in tciMaintAuditLog is 9-10-2002
Can we safely remove records older than a certain date without negatively impacting Sage's ability to troubleshoot if needed?
Thanks.
In respect to tciDBActivityLog, the first thing to understand is that there should be few, if any, rows in this table. Although it was originally added to log direct back-end changes for Support, it can be used by anyone to monitor or review changes made to data in native Sage schema. You should be reviewing the origination of those rows, what was modified and by what application or user. I've used it numerous times to eliminate or identify front-end problems created by vendors or clients, as well as tracking down users that gained access to the back-end for nefarious purposes. There is no front-end switch or method to turn this logging off or to purge rows, and they are lacking specifically because you should be researching their origin and know something of how to manage this logging.
The tciMaintAuditLog table is the repository for the auditing enabled by the user that is available for entity types of data. The settings that control this logging are available in modules like AR, AP and IM in each company in the system. The basic report is available in SM and Sage added an Explorer view into this data in one of the recent versions.
You can remove the audit log data using the standard purge utility for the module in which you're working. This will generally delete rows that are beyond the retention setting. The audit log data has many potential uses. For example, I once added a view to it for a CRM interface so users could research changes to customer accounts.
If you elect to remove rows from these tables manually, you are potentially creating a separate set of problems, and Support, your reseller or consultant could elect to close an issue without resolution because you modified back-end data, or charge you more than a pocketful of change to fix it. And yes, there are other markers to identify back-end modifications. Something to keep in mind.
In respect to tciDBActivityLog, the first thing to understand is that there should be few, if any, rows in this table. Although it was originally added to log direct back-end changes for Support, it can be used by anyone to monitor or review changes made to data in native Sage schema. You should be reviewing the origination of those rows, what was modified and by what application or user. I've used it numerous times to eliminate or identify front-end problems created by vendors or clients, as well as tracking down users that gained access to the back-end for nefarious purposes. There is no front-end switch or method to turn this logging off or to purge rows, and they are lacking specifically because you should be researching their origin and know something of how to manage this logging.
The tciMaintAuditLog table is the repository for the auditing enabled by the user that is available for entity types of data. The settings that control this logging are available in modules like AR, AP and IM in each company in the system. The basic report is available in SM and Sage added an Explorer view into this data in one of the recent versions.
You can remove the audit log data using the standard purge utility for the module in which you're working. This will generally delete rows that are beyond the retention setting. The audit log data has many potential uses. For example, I once added a view to it for a CRM interface so users could research changes to customer accounts.
If you elect to remove rows from these tables manually, you are potentially creating a separate set of problems, and Support, your reseller or consultant could elect to close an issue without resolution because you modified back-end data, or charge you more than a pocketful of change to fix it. And yes, there are other markers to identify back-end modifications. Something to keep in mind.
*Community Hub is the new name for Sage City