[Users] Re: [Serusers] acc module db_extra accounting issue

Bogdan-Andrei Iancu bogdan at voice-system.ro
Wed Feb 8 12:07:43 CET 2006


Hi Marcello,

I run several tests but I was not able to reproduce the problem. Here is 
what I tried:

    modparam("acc", "db_extra", "customer_code=$avp(i:102)")
    ....
    avp_db_load("$from","i:102");
    avp_print();
    t_relay();
    ....

and here is what I had in DB:
+------+----------+---------+-----------+------+-------+---------------------+
| uuid | username | domain  | attribute | type | value | 
modified            |
+------+----------+---------+-----------+------+-------+---------------------+
|      | bogdan   | test.ro | 102       |    3 | 12    | 2006-02-08 
12:46:29 |
+------+----------+---------+-----------+------+-------+---------------------+
 
the "12" value was written in the DB with not problem.

I suspect that the problem is somewhere else and not in acc.
BTW, how do you create the AVP "i:102"? you your original mail, the 
avp_print shows a "0" flag for the avp; and the avps loaded via avpops 
have a flag set to indicate that it originated from DB.

any progress on the issue?

regards,
bogdan


Marcello Lupo wrote:

>Hi,
>yes i'm sure that there is no further processing in the script.
>As i wrote in a previous email if i change the value type from 3 (int int) to 
>2 (int string), and not changing anything else, the value is accounted 
>correctly.
>I was only using type 3 (int int) for performances reason as the values are 
>managed from Openser. If you tell me that there is no difference, in 
>performance) between the 2 way of handling values i can use all of them as 
>type 2 (int string).
>Anyway i will try to change type of column in the acc table from int to 
>varchar leaving the avpops values as type 3 (int int) to check the difference 
>if any.
>Thanks,
>Bye,
>Marcello
>
>
>Alle 10:26, domenica 29 gennaio 2006, Daniel-Constantin Mierla ha scritto:
>  
>
>>Hello,
>>
>>the columns for extra accounting in the acc table must be varchar(). The
>>acc module prints the extra variables as string in database. Anyhow, as
>>far as I know, it should work with columns of type int, mysql accepts to
>>insert a quoted integer (e.g., insert into table test (int_column)
>>values ('1234') - is a valid statement).
>>
>>Are you sure that there is no other processing in the script of that
>>avp? Please note that the accounting record is written when the reply is
>>received.
>>
>>To check the proper functionality use following example:
>>        avp_write("i:12", "i:102");
>>        acc_db_request("done", "acc");
>>
>>And then check the record in database.
>>
>>Cheers,
>>Daniel
>>
>>On 01/27/06 12:51, Marcello Lupo wrote:
>>    
>>
>>>Hi,
>>>acc ver:
>>>
>>> * $Id: acc.c,v 1.5 2005/07/05 15:43:38 anomarme Exp $
>>>
>>>avpops ver:
>>>
>>>* $Id: avpops.c,v 1.14 2005/09/12 17:20:10 miconda Exp $
>>>
>>>I'm using stable tls version of openser 1.0.0 and shipped modules.
>>>Thanks,
>>>Bye,
>>>Marcello
>>>
>>>Alle 11:45, venerdì 27 gennaio 2006, Bogdan-Andrei Iancu ha scritto:
>>>      
>>>
>>>>Hi Marcello,
>>>>
>>>>what version are you using?
>>>>
>>>>regards,
>>>>bogdan
>>>>
>>>>Marcello Lupo wrote:
>>>>        
>>>>
>>>>>Final information.
>>>>>If i change the avp type from 3 (int_int) to 2 (int_string) it is
>>>>>accounted correctly.
>>>>>May be a bug in how int int avp values are passed from avp module to
>>>>>acc module?
>>>>>Thanks,
>>>>>Bye,
>>>>>Marcello
>>>>>
>>>>>Alle 11:32, venerdì 27 gennaio 2006, Marcello Lupo ha scritto:
>>>>>          
>>>>>
>>>>>>Hi,
>>>>>>more information about it..
>>>>>>I changed the value to 55 and it is now written in the table as 51 .
>>>>>>Thanks
>>>>>>Bye,
>>>>>>Marcello
>>>>>>
>>>>>>Alle 11:27, venerdì 27 gennaio 2006, Marcello Lupo ha scritto:
>>>>>>            
>>>>>>
>>>>>>>Hi,
>>>>>>>i have a db_extra accounting rule like:
>>>>>>>
>>>>>>>modparam("acc", "db_extra", "customer_code=$avp(i:102)")
>>>>>>>
>>>>>>>The avp value is 12 and i checked it with avp_print() .
>>>>>>>
>>>>>>>DEBUG:avpops:print_avp: p=0x2a97a866e8, flags=0
>>>>>>>DEBUG:                 id=<102>
>>>>>>>DEBUG:                 val_int=<12>
>>>>>>>
>>>>>>>When it is accounted in the table the value become 11 !!!!!
>>>>>>>the field in the table is type int(10) .
>>>>>>>
>>>>>>>How is it possible??
>>>>>>>Thanks,
>>>>>>>Bye,
>>>>>>>MArcello
>>>>>>>              
>>>>>>>




More information about the sr-users mailing list