This article was inspired by public postings on the RES forum, where examples show how to dive into the RES PowerFuse datastore using simple SQL queries to do what you need.
WARNING: This article adresses modifying the RES PowerFuse 2008 SR3 database directly. There is absolutely NO guarantee that the specifics of this article will work in future versions of PowerFuse as database layout may change. Second, this article may become redundant if RES implements the ability to to clear individual logfiles in a later version. Third, if you use the settings in this article, you are ON YOUR OWN, as it’s most likely not supported by RES that you are poking around in their datastore. Last item on the warning agenda: Back-up your database before proceeding. If you don’t know how to do that, it is likely that you should not be attempting to mess around with these things in the first place.
Currently, in PowerFuse 2008 SR4, to which this article applies, you can only clear all logfiles at once, or delete all but the last 10 days of records. These features are to be found beneath the Maintainance node in the management console.
However, the situation may arise where you need to blow out one or more logs, while keeping others. This is especially true if you are in a Proof-of-Concept or initial build phase of a project, where you’ve got things running in learningmode all over the place, and you need to do some housekeeping. Again DO NOT do this in a production environment.
All of this ofcourse requires you to have proper database credentials. Another good argument right there, why to be vigilant about your SQL security. So this article will remedy the situation.
A couple of notes:
- The article only covers the regular logfiles inside PowerFuse as they are in one table. PowerTrace and Auditlogs are subjects for other articles.
- This method and the associated Wisdom buildingblock has only been tested on MS SQL. If Oracle needs things in a different way has not been clarified.
First things first, let’s get an overview of what we’re dealing with. Inside the RES PowerFuse datastore there is a table called tblLogs which contains all the logfiles, PowerTrace and Auditlog excluded. This means that powerlaunch eventlogs, cpushield logs, errorlog, etc etc are all bundled into one table. This is fine, but we need to get rid of some of the records. Fortunatly the column lngClassID will tell us what type of log each record represents. Below is a list of the values for lngClassID
- 10 = Partially Managed Workstation log
- 23 = AppGuard security log
- 24 = File and Folder security log
- 25 = Read-Only Blanketing log
- 26 = Removable Disk Security log
- 29 = SessionGuard log
- 30 = CPUshield log
- 31 = MemoryShield log
- 46 = PowerFuse Error log
- 47 = PowerLaunch Event logs
- 48 = Sample data (User Settings on apps)
- 54 = NetGuard (IP security) logs
- 58 = Wisom Integration
With the above info in hand, it is easy to construct a SQL statement to do what we need. It should look like this: With the above statement in hand it is easy to put together an SQL statement which will get rid of the unwanted logs. It should look like this:
DELETE FROM tblLogs WHERE (lngClassID = NN)
Where NN is the number from the list above which represents the log you want to get rid of. With the above information at hand it is quite easy to put together a Wisdom module that will do this. Again, this module is just for demonstration purposes. If you run it on your production environment and something goes horribly wrong, it’s your own fault, nobody else.
Note: The building block does not currently contain an entry to delete User Settings sample data. This is however strictly not necessary, as there is a button to clear that log per application. The same goes for the Error log.
No comments yet.