dealing with 'corrupt' detail file

[A.L.M.Buxey at lboro.ac.uk]

hi,

okay. so i've been preaching that people use eg
the buffered-sql virtual machine rather than do accounting
DB entries 'live' - therefore giving the admin better
FR performance with slower DBs etc...

however, I've been approached today by someone who has a
rather large detail file (few gigs) that has 'corrupt'
records in it... eg entries with no Acct-Status-Type
set (broken NAS, duff RADIUS server or possibly
attrbute filtering along the path)...anyway, my first
though was edit the accouting stanza of buffered-sql
so that it looks like

if(Acct-Status-Type){
  sql
 }

instead of just calling sql and borking over the
lack of Accounting status in the packet.

but, of course, whilst this stop the bork, it also
stops the ingestion of the detail file as it sticks
at that point, doesnt flush that entry and move on...
so...can anyone info me the magic or steps to bypass
this entry in the detail file so it can continue
working on it? the code itself seems to need to go
through something before flushing the packet..

..i expect to then be told there are other broken
records too - but i hope a simple solution can deal
with all sorts.... then I can get them to ensure
that the call to detail is protected in the first
place so NULL records etc dont even go in.

which reminds me...any best practice from the
FR community regarding the detail file and
the aforementioned protection from duff NAS etc

(I've already got, on my list, use Calling-Station-Id
instead of NAS-Port for the unique function as many
NAS use the same port for every accounting packet :-|)


thanks

alan