There is allready a trigger on the calls table that runs and updates the
serverports everytime your RADIUS server receives a start or stop request.
This process is allready occuring so adding a few extra fields should have
no noticable effect on performance. The trigger does not query the calls
table so the size of this table is irrelevant.
Adjusting the trigger will allow you to grab any accounting attribute that
your NAS logs and update your serverports table. "callsonline" is just a
view of the serverports/servers tables to make this info easier to read.
At 02:54 PM 10/28/99 +0300, you wrote:
>We do not want to do such an operation, because calls table getting big
>everyday (even we clear it once a month)
>and when we set a trigger on it, trigger will consume all SQL server
>resources (CPU), and makes a very high load.
>But I think there must be a structure like the one done on Calls (RadiusNT
>load all column info at startup)
>RadiusNT can load all columns on serverports table at startup, and then
>collects that data from the radius request,
>then updates serverports (not callsonline)
>Why not ?
>Is not that a good idea ?
>>Using MSSQL's enterprise manager, you can easily alter the serverports
>>to include the new columns and then update the insert trigger on the calls
>>We find that 'connect-speed' is another handy one to see in the calls
>From: Serkan SUBASI <firstname.lastname@example.org>
>To: email@example.com <firstname.lastname@example.org>
>Date: Thursday, October 28, 1999 3:30 PM
>Subject: [RadiusNT] What about writing CalllerID, AcctSessionID to
>callsonline (serverports) ?
>>What about writing CalllerID, AcctSessionID to callsonline (serverports) ?
>>Because we never know a user s CallerID, unless user disconnects, and
>>queries made to calls table is slower than those made to serverports
>>thanks in advance
>For more information about this list (including removal) go to:
For more information about this list (including removal) go to: