6 Jan
2016
6 Jan
'16
12:48 p.m.
Hi to both Daniels and thank you for your responses.
I understand what you are both saying.
Currently the field I am extracting the value from in the database is set to type;
bigint(20) unsigned
If I change to varchar for example it returns fine, my only issue is that the overflow
only occurs on 10 digit numbers starting with 2 or 3.
If I add a value for example 1785702370 or 7785702370 they are returned without issue
without changing the DB value type.
Thanks
Jon
To: sr-users(a)lists.sip-router.org
From: miconda(a)gmail.com
Date: Tue, 5 Jan 2016 19:49:02 +0100
Subject: Re: [SR-Users] Negative value returned when using sql_pvquery
On 05/01/16 17:51, Daniel Tryba wrote:
On Tue, Jan 05, 2016 at 03:38:58PM +0000,
Jonathan Hunter wrote:
To complete, as just looked at the source -- if the bigint number
returned does not fit in 32bit size, then it is stored as string. If it
fits in 32bit, then is stored also as int. I see the code was added in
2011 by Alex Hermann.
Maybe the behavior is not that coherent, hard to predict if not knowing
what is in the db, and should be changed to be always stored as string,
then use {s.int} in config if wanted as int.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
http://miconda.eu
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users sql_pvquery("cd","select
DestinationMsisdn,SourceMsisdn from MsisdnPoolAllocations where
PoolMsisdn='$rU'","$var(MOdest),$var(NewSourceMSISDN)");
However this returns a value of -509264926 for $var(MOdest) which should just be the
3785702370 number.
What can cause kamailio to interpret this as a negative value? Has anyone seen this
before?
What you are seeing is an integer overflow, in this case you are trying
to store a number greater than 2^31 in a signed 32bit int. -509264926
(3785702370-2^32) is the correct answer if the var is a signed 32bit
int.
I treat phonenumbers as strings (both in the database and kamailio)
since I store them as E.164 with a leading + (which results in a bit
more diskspace)
If you don't need the number as int in kamailio, try casting it to a
string in the query.