Login Auditing violates Unique Contraint on F9312

All,

We have been testing login/logoff auditing on our servers. This is done by setting the following entry on the enterprise server:

[SECURITY]
History=1


Once this is set, anytime a user logs in using the security kernel on the enterprise server that this is set on, an entry will be created in the F9312. This is all fine and dandy, EXCEPT errors are created when processes issue multiple logins at the same hour/minute/second combination, such as when services are started, or XPI is logging in, or your scheduler launches multiple processes with the SAME id at the same time. The reason this is happening is because the logging mechanism is only inserting the hour/minute/second, which is 6 characters. My thought is that this would not be an issue if the miliseconds were included by the logging mechanism, I have looked at the field, and only 6 of the possible 10 characters is being used.

This is an issue for us because we have scheduler jobs running throughout the day, and we also have a pretty large amount of XPI transactions. So, needless to say, this will make our logs grow very large in a short amount of time.

Has anyone else ran into this issue??

Any help is appreciated....

This is one of those known problems that although easily fixed they never get around to fixing.

I have used two approaches to work around the problem:

* Remove the primary key completely

* Add an additional column to the primary key. On that column I place a DEFAULT value that uses the DB-specific timestamp function to automatically place a high-resolution timestamp in the field and therefore guarantee uniqueness.

I believe there are some canned reports that work over the F9312. I never use them and use either queries or custom UBEs. I cannot speak to the effect my two workarounds might have on the canned reports but I have not had any problem with the logging mechanism with either of my workarounds.

Hope this helps ...

Thanks for your suggestions.. I have since learned that this issue is supposedly resolved in Tools Release 8.95. We had thought about adding an additional column, but we didn't want to stop anything from working correctly. We also though about adding a trigger to the table that changes the time stamp BEFORE the insert happens, maybe create a new Next Number to be inserted instead of the time...

Matthew