>This is what I'm getting in radius.
> Acct-Session-Id = "02000012"
> SQL Statement: INSERT INTO Calls
>(CallDate,AcctSessionId,UserName,NASIdentifier
>,NASPort,AcctStatusType,NASPortType,UserService,FramedProtocol,FramedAddress
>,AcctDelayTime) VALUES GetDate(),'02000012','nilles','206.156.227.3'
>,9,1,0,2,1,'206.156.227.153',0)
This was mumbo jumbo to me, too, until Jeff Albright showed me this:
Go to SQL Enterprise Manager. Connect to your SQL server that houses the
EMERALD database. Start the Query Tool from the toolbar. Select the
EMERALD database as the one to query, and then in the query box, type:
select * into Calls
Then execute the query. This is a record of everyone who called you in the
past "x" days. (I am still unsure as to when this gets cleared or
updated). If you look, you'll see a logon and a logoff record for each
caller, with matching session ID's.
>ODBC: SQLExecDirect Error:
> [Microsoft][ODBC SQL Server Driver][SQL Server]Violation of PRIMARY KEY
>constraint 'pk_Calls': Attempt to insert duplicate key in object 'Calls'.
>Sending Accounting Ack of id 192 to ce9ce303 (usr1.linkup.net)
When you get THIS, it seems to me to be a problem with duplicate accounting
session ID's. In your case, you can probably locate a session ID of
02000012 from an earlier time, and thus, it cannot be "re-used". (Please
correct me if I'm wrong -- I truly want to understand this).
>This started happening after I reset my NAS. It was acting up. I am
>talking with my vendor but am not sure I am being fed the correct
>infrmation. Can someone tell me exactly how the AcctSessionID is
>generated? Is it entirely by the NAS at the point the call is started or
>how? I assume this is the duplicate key right?
Yes, and as you saw in my post (must have been composing it right as you
were) it looks like the NAS generates it, based on the NAS's reset time.
When I reset my NAS, the numbers start over again, too, and if those
numbers are STILL in that calls database, then I get the accounting errors
you spoke of, and I lose lots of data. The only way around this is to
ensure your NAS never crashes. Fat chance.
Anyone have a clue on how to solve this one? Erik's problem seems related
to mine, in being able to pull the data back OUT, and in having duplicate
session ID's from different NAS's in conflict....