Thanks. Been there too, but not this time. Plenty of room in both parts of
the database. Hopefully I can figure out why this thing quit, since I am
getting killed by multi-linkers who figured out my concurrency checking
wasn't working. The stop records seem to be coming, just not being
assimilated by the database. I going after the auth log next. Hopefully
there is a clue in there somewhere.
Sam
----- Original Message -----
From: Josh Hillman <admin-maillist@talstar.com>
To: <radiusnt@iea-software.com>
Sent: Tuesday, September 07, 1999 6:02 PM
Subject: Re: [RadiusNT] Concurrency problems
> From: Sam Lowe <slowe@universalcom.net>
> > All of a sudden our concurrency checking quit (almost) last Friday. We
> > noticed it was getting sporadic over the previous few days, but put it
off
> > as a problem not getting stop records from a particular NAS. Thinking
it
> > was possibly and indexing problem, I created a new empty calls table,
> > stopped the database and renamed the tables and cranked it back up.
Even
> > with just a few records we were not getting the the stop records posted
> > promptly (I think). I get only ODBC timeout errors when I write an
access
> > query, so I'm going to go back in with ISqlw to see if I can determine
if
> > were missing stop records.
>
> Has the data segment of your database filled up? I ran into this problem
a
> week ago; it turns out that my Emerald database filled up. The Calls
table
> is growing incredibly quickly now because of the plethora of Stop records
> being generated by the second ISDN channels going up and down constantly
> from DBA.
>
> Josh
>
>
> For more information about this list (including removal) go to:
> http://www.iea-software.com/support/maillists/liststart
>
For more information about this list (including removal) go to:
http://www.iea-software.com/support/maillists/liststart