HI All,

I have seen so many posts on similar issue yet I feel this is new.
Users got the usual 254 error for audit [as the sequence could not be overwritten]. Purging the sequence helped. On further analysis I saw the audit_spec file is set up as below:

*:*:TOSEQ 999 SECURITY 28 MAXSEQSIZE 2048K

1. Though the toseq is set to 999 the max seq ever reached is 14. Why? :confused:
2. Also, seqreuse is not mentioned yet some tables 000th sequence is getting overwritten at the same time some get stuck with 254. Any ideas?

The only thing which seems to be working as set is the MAXSEQSIZE.

Is there any other file which overrides the setup in audit_spec file?
Also where does audit_set file reside?

BTW, this is a 5.0b system.

1. Though the toseq is set to 999 the max seq ever reached is 14. Why?
Because the <table_name>.inf file has that info. It might have got that info from the previous audit spec settings and you changed it now.
Also, seqreuse is not mentioned yet some tables 000th sequence is getting overwritten at the same time some get stuck with 254.
Are you doing regular audit purging ?
Is there any other file which overrides the setup in audit_spec file?
Also where does audit_set file reside?
Refer to the Tools Administrator Guide for the Audit Management.
$BSE/lib/audit_spec

Refer to the threads -

audit server --urgent (http://www.baanboard.com/baanboard/showthread.php?t=1608&highlight=254)

Audit Errors (http://www.baanboard.com/baanboard/showthread.php?t=5396&highlight=254)

Because the <table_name>.inf file has that info. It might have got that info from the previous audit spec settings and you changed it now.

I checked the audit sequence it is indeed not updated. I didn't change the spec file recently. At any rate, how is this supposed to be corrected?

Are you doing regular audit purging ?
No it is not being done at all. As was under the assumption the files are being reused.

Is there any other file which overrides the setup in audit_spec file?
Also where does audit_set file reside?

Refer to the Tools Administrator Guide for the Audit Management.
$BSE/lib/audit_spec

Didn't get much help in the file other than the format. Our file is as per the guidelines mentioned.

Nancy,

I am on a latest BaaN version than yours. Hence, I would not like to suggest a work-around for this issue.

Here is some info from our case-

I guess the main issue of the customer is that the users can continue to work without being disturbed by the fact that audit files need to be purged.
In the past the REQREUSE was a solution in that by allowing forced overwrite of auditfiles.But as the audit implementation is changed (also registration in audit table) and due to the forced overwrite this is not possible anymore.

2003-07-29[15:01:56(UTC+05:00)]:E:bsp: Log_mesg: For table tsctm000410, the obsolete 'SEQREUSE' flag was
used.

Its depreciated for (atleast) our Version. I am not sure on yours. You have to work with BaaN Support or others working on same version can help you.

Probably this is what must have happened:


1. Though the toseq is set to 999 the max seq ever reached is 14. Why?

The .inf files were updated manually using taudit6.2

seqreuse is not mentioned yet some tables 000th sequence is getting overwritten at the same time some get stuck with 254. Any ideas?


When audit was initially setup audit_spec file must have had reuse parameter. Audit server looks at this parameter the first time the .inf file is generated. Down the line the audit_spec file was changed and some .inf files were either removed or were newly created with Audit being turned ON for the table. These new .inf files did not have the reuse parameter. Thus we end up with 254 for some tables but not all.


I am going to do the following:
1. Update the audit_spec file with seqreuse parameter.
2. Move all audit files out from the audit directory.
3. Wait for the .inf and seq files to be created as users start transactions.

This will resolve the issue (in theory)!! :D

Reuse parameter is not usable starting from porting set 7.1d in BaaN 5.0b.
BaaN doesn't provide any good way to clean up old audit files either. On my pestering a lot, BaaN Support opened up an ehancement request where the purge audit files session can be run with a date field rather than sequence number. With this feature available we can think of some kind of automation for audit file purge.

Nancy,

I logged my case in Aug'2003 and I dont have a solution yet. I think it might be due to the Audit Functionality changes in Gemini and that some of the Porting sets are also forward/backward compatible across the Reger and Gemini.

I am not sure in your BaaN version, but the Purge Audit has the date based option in our Version. Add it to a job for automation.

Yep, that seems to be the difference between 5.0b and (Reger and higher versions). The date field makes it easy to make a routine job (automate the cleanup). Without that its quite a manual job. The brunt of which we are facing currently.

Nancy,

In our version there are only 6 audit tables and I figured out the logic only 1 table is used. I am not sure of the options on your purge audit session, you can either build a AFS wrapper to the tools session or make a shell script and a sql to clear up based on dates and selection ranges.

Good Luck