[OpenSIPS-Users] cdrtool: looking in the wrong location for radacct table when mysql on the same IP address?

[Adrian Georgescu]

On Apr 27, 2010, at 10:06 AM, Paul Wise wrote:

> [Please CC me on reply]
>
> I'm getting this error from cdrtool 7.7.1:
>
> MySQL error: 1146 (Table 'opensips.radacct201004' doesn't exist)  
> Table 'opensips.radacct201004' doesn't exist
>
> cdrtool seems to be looking at the opensips database instead of the
> radius database for the radacct tables.
>
> I found a couple of references to this problem:
>
> http://google.com/search?q=cache%3Acdrtool.ag-projects.com%2Fticket 
> %2F1
> http://www.openser.org/pipermail/users/2009-January/002710.html
> http://lists.sip-router.org/pipermail/sr-users/2008-October/ 
> 019889.html
>
> The latter thread ended with the guy rewriting cdrtool from scratch,
> which I definitely do not want to have to do just yet.
>
> The ticket tagged worksforme from the google cache suggests a  
> workaround
> of changing the IP address of the database server. Since my database
> server has two addresses I tried that, which fixed the radacct error  
> and
> I can list calls fine.
>
> The call search now gives another error:
>
> MySQL error: 1146 (Table 'cdrtool.subscriber' doesn't exist) MySQL  
> error: 1146 (Table 'cdrtool.grp' doesn't exist) 5 CDRs normalized.  
> Quota usage updated for 5 accounts. For more information about each  
> call click on its Id column.


>
> These tables are in the opensips database, not the cdrtool database.
>

I have no clue how you arrive at this situation. I  maintain many  
installations and I have not seen or being able to reproduce this  
behaviour so far.

Adrian


> So I then allocated some more IP addresses for the database server and
> put one IP address per DB_Sql class in global.inc. That resolved all  
> the
> missing database table errors I could find, including the one I  
> reported
> in the last thread I wrote:


>
> MySQL error: 1146 (Table 'opensips.active_sessions' doesn't exist)
> Session halted.
>
> Is there a better way to fix this than allocating a bunch of IP
> addresses for the database server?
>
I believe that there is simply a wrong setting somewhere and all  
solutions miss the forest because of the trees. But is just a guess.

Adrian