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