Category Archives: Ajax

MySQL and the mystery of wrong numbers… always check your numeric types!

Doh! Another half hour wasted!

I just spend the better part of half an hour searching for a bug in my PHP scripts that update a MySQL database via an AJAX call. One of the fields in the database table is numeric, integer to be precise. When I tried to update the field with the value 228, the database would always change the value to 127. Why? All the other queries worked correctly. The field happily accepted a 48, a 85 and a 126. But the 228 always turned out as a 127.

Of course, it’s a late Friday afternoon and technically I should be doing more mundane things like writing a blog post, doing my timesheets or having a beer or two. But instead I was stuck with this issue. Just fix this issue and the scripts were good to go! Just this one tiny problem. Must be a typo somewhere in the PHP script. Or is jQuery somehow tinkering with the input field value before the form data is being sent? What could it be? What, what, what?!?

Then, all of a sudden, something made click and I couldn’t avoid a solid facepalm. I checked the database setup and found that the numeric type for the field was set to “tinyint” instead of “smallint”. And as we all should know unsigned tinyint’s maximum value is 127. Everything greater than that will be “rounded” to 127.

Now the field type is correctly set to “smallint” and my script is working. I just wish I could get that wasted half hour back and use it for mundane things like writing a blog post about those little blackouts that often cost too much time.

Oh well, time for a beer…

google.maps.LatLng spits out NaN

Well, this is one of those examples that shows it pays off to sleep a night over certain problems.

Yesterday afternoon I scratched my head over the Google Maps V3 API’s behaviour. All I wanted to do is change the zoom level of a map using the fitBounds() method. The latitude and longitude values were coming from a jQuery Ajax request that returned an JSON object. The object looked something like this:

{
     "bounds": {
          "sw":"-45.99579575,170.05493469",
          "ne":"-45.48679779,170.77724915"
     }
}

I tried the following script to set the new bounds:

var obj = jQuery.parseJSON(ajaxResponse);
sw = new google.maps.LatLng(obj.bounds.sw);
ne = new google.maps.LatLng(obj.bounds.ne);
newbounds = new google.maps.LatLngBounds(sw,ne);

Now, the result was that it completely caked the Map. The map literally zoomed (or panned, who knows?) to uncharted territory after which any interactions with it would not result in any updates. The map had effectively crashed.

WTF, why? I asked myself. So I checked what values google.maps.LatLng were producing. NaN. Not numbers obviously, but why? I chewed on that for half an hour before I decided to leave it for the day.

Now this morning I had a look at it again and it quickly dawned on me… the JSON data was delivered as a string but the google.map.LatLng class expects floats. So I altered the script accordingly:

var obj = jQuery.parseJSON(ajaxResponse);
var sw=obj.bounds.sw.split(','); // split string to allow parseFloat of data
var ne=obj.bounds.ne.split(',');
sw = new google.maps.LatLng(parseFloat(sw[0]),parseFloat(sw[1]));
ne = new google.maps.LatLng(parseFloat(ne[0]),parseFloat(ne[1]));
newbounds = new google.maps.LatLngBounds(sw,ne);
map.fitBounds(newbounds);

And lo and behold… it works.

IE Ajax woes – Internet Explorer caching of Ajax requests

It happened again. A stone old IE bug got me cold. For some strange reasons Internet Explorer caches Ajax requests. Which means that if database info is extracted via an Ajax GET request, Internet Explorer will store the Ajax response in its cache for the current session. So if the database is updated during the session, Internet Explorer will show the zombie values from before the database update.

Best way to avoid this is to issue an Ajax POST request instead of GET.

More info here.