You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
Latest Tweets
- We come to @first_watch almost every weekend. I crave the tri-fecta come 7 AM every Sunday. posted @ 9:39 AM, Jul 05th
- #moonfruit pancakes forbreakfast! posted @ 9:09 AM, Jul 05th
- Eating some 4th of July #moonfruit . posted @ 8:45 AM, Jul 04th
- Unless Sarah Palin is going to buy me a Mac, she should shut up until #moonfruit is over. One more reason... posted @ 5:18 PM, Jul 03rd
- F'ing Wild West pinball makes me mad. I always lose the ball down the sides. posted @ 5:06 PM, Jul 03rd
Popular This Month
- The Decemberists' "The Hazards of Love": An Interpretation 79 comment(s) | 125 view(s) per day
- Megan Fox Analyzes Her Farts 0 comment(s) | 92 view(s) per day
- Review: Picasaweb vs. Flickr 24 comment(s) | 67 view(s) per day
- Flip 3.0.1 0 comment(s) | 51 view(s) per day
- Moment of Silence 3 comment(s) | 47 view(s) per day
Recently Shared Links
Popular Tags
-
Apple
Code
Development
Flip
Food
Funny
Google
iPhone
Links
Mac
Meta
Microsoft
Music
Nerd
OSNews
Phish
PHP
Politics
Random
Rant
Review
Small Axe
Social Commentary
Software
TV
Videos
Web
Web 2.0
Websites
YouTube
From the Vault
- July 2009 (1)
- June 2009 (6)
- May 2009 (5)
- April 2009 (8)
- March 2009 (12)
- February 2009 (10)
- January 2009 (12)
- December 2008 (9)
- November 2008 (16)
- October 2008 (11)
- September 2008 (18)
- August 2008 (18)



Integers on the Intertubes
Some time ago, I wrote an application for my company. Like most weblets I’ve written, this used PHP and either MySQL or MSSQL for the backend. This particular application logged all phone calls. As part of the record, it would record the caller’s account number, which is a 5 or 6 digit integer.
So, I got a phone call from the director of our customer contact department this week. He was concerned about the reports. He made a decision last week that when a call came in that was a lead – in other words, a non-customer, that his people would fill the phone number from the caller ID into the account number field. But when he ran his export reports, he found that hisn techs had entered this phone number for ALL of the calls: 429-496-7295. That’s weird, he said. So he called me and asked why that was. I checked all the calls and most were from one woman, so my first instinct was “Check if her browser has autocomplete turned on”. But he swore that he tried it too and gotten the same result.
I checked the database and sure enough, it was right there: 429-496-7295, in all of the fields. So I went back to the code. In short, I took the input from the form, and declared it like this:
Pretty straightforward: explicitly declare the type. So, I started my debugging by attempting to manually enter the data into the database. Sure enough: the account key field showed this: 4294967295.
So, I went back to the PHP and started by dumping out the raw SQL query:
What? So the database automatically converts it to this weird phone number and PHP does too? Suddenly it occured to me. One of the benefits of 64-bit computing is the ability to address more memory. There are limits to what can be done in 32-bit computing, and one is that integers have a limit! In this case, a database field called “integer” is limited to numbers between -2,147,483,648 and +2,147,483,647. It just so happens that the number is the same length as a US phone number – 10 digits. Changing the db field to “BIGINT” allowed me to manually run the SQL query and it worked. But the app still didn’t.
PHP’s int() and (int) $var syntaxes both conform to the integer limit. So I devised a work around:
It’s not gorgeous, but it will more than suffice for an internal app. We web programmers don’t usually have to deal with big integers, so it’s totally possible that web developers would never have had occasion to handle a situation like this. Here’s looking forward to native 64-bit for our next server, though.