We checked the time-out in all of our TNT's/MAX's - we have a TNT and 5
MAX 4000/6000 - they are all set to 10 seconds. We are still getting the
"'pk_Calls'. Cannot insert duplicate key in object 'Calls'" error.
Checked on triggers on the calls table - looked under the 'triggers' for the
calls table and found nothing! Where should we find them, and what
triggers should be there?
We created an Index as suggested by Mike Miller in a post on 3/17/99 as
CREATE INDEX index_AcctSessionId ON Calls(AcctSessionId)
This was done earlier - we have had several 100% CPU incidences since!
We have been using the Access DB version of RadiusNT since you first
introduced it - we have had to do absolutely no maintenance on the system -
since we introduced MS SQL we have had to spend a lot of time learning
the internal problems and specifics of SQL - I'll be glad to get this to settle
down again!!! I'm thinking that maybe MS SQL was not the best choice -
maybe we should have considered ORACLE?
Any thoughts?
----------------
Email from: Dale E. Reed Jr. <radiusnt@iea-software.com>
On 8 Jun 99, at 10:43, Dale E. Reed Jr. wrote
> Michael Hobach wrote:
> >
> > Any thoughts on this previous post?
> > This 100% thing is driving us crazy...
>
> > > First, with ODBC logging turned on, we keep getting errors logged like
> > >
> > > ODBC Error:23000:2627:
> > > [Microsoft][ODBC SQL Server Driver][SQL Server]Violation of PRIMARY
> > > KEY constraint 'pk_Calls'. Cannot insert duplicate key in object 'Calls'.
>
> This just means RadiusNT already has the accounting record. Its normal,
> but you shouldn't see it a lot. If you do, then check your timeouts and
> the response times of RadiusNT.
>
> > > ODBC Error:37000:170:
> > > [Microsoft][ODBC SQL Server Driver][SQL Server]Line 1: Incorrect syntax
> > > near 's'.
>
> This is typically someone putting a ' in a username or such.
>
> > > Second, about once a week the SQL server goes to 100% processor
> > > utilization. Stopping RadiusNT and Cold Fusion does nothing. It appears
> > > that the RadLogs table may be the problem - deleting the RadLogs table
> > > brings the server back down to realistic CPU utilization.
>
> Someone reported this a while back on SQL7. It has to do with the
> trigger. There was a posted workaround for it, but I don't remember
> the exact problem. I think it had to do with aliasing (or lack thereof)
> the update table vs. using the table name. What does your trigger
> on your calls table look like?
>
>
> --
>
> Dale E. Reed Jr. Emerald and RadiusNT
> __________________________________________
> IEA Software, Inc. www.iea-software.com
--------------------------------
Michael Hobach <mhobach@cyberlynk.net>
CyberLynk Network, Inc.
6214 Washington Ave Suite C16
Racine, WI 53406
(414) 884-1088 Fax (414) 884-1053
http://www.cyberlynk.net