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