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
>>>>>>>
>>>>>>>