I recently had a issue getting MySQL to read a specific database. Each time I tried to manually query a table in the database, I received the following error message:

ERROR 1018 (HY000): Can't read dir of './default/' (errno: 13)

I’ve seen this message before as it means that there is a permissions issue. I checked the ownerships and permissions, and everything seemed to be in order.

The only thing special about this database is that I have it symlinked to another partition. This has always worked in the past, so I was stumped.

The problem turned out to be that Ubuntu has AppArmor. This software sets up rules that prevent software from gaining access to different areas of the file system. In my case, AppArmor was preventing read and write access to the actual location of my database files.

The solution was quite easy: First, I added the path that I wanted MySQL to have access to in the AppArmor configuration file for MySQL. Second, I restarted the apparmor service. Here’s the technical details:

1. On my system, the configuration file that controls MySQL permissions through AppArmor are located at /etc/apparmor.d/usr.sbin.mysqld. The following shows the contents of the file as it now exists:

   # vim:syntax=apparmor
   # Last Modified: Tue Jun 19 17:37:30 2007
   #include 
   
   /usr/sbin/mysqld {
     #include
     #include
     #include
     #include
     #include 
   
     capability dac_override,
     capability sys_resource,
     capability setgid,
     capability setuid,
   
     network tcp,
   
     /etc/hosts.allow r,
     /etc/hosts.deny r,
   
     /etc/mysql/*.pem r,
     /etc/mysql/conf.d/ r,
     /etc/mysql/conf.d/* r,
     /etc/mysql/my.cnf r,
     /usr/sbin/mysqld mr,
     /usr/share/mysql/** r,
     /var/log/mysql.log rw,
     /var/log/mysql.err rw,
     /var/lib/mysql/ r,
     /var/lib/mysql/** rwk,
     /var/log/mysql/ r,
     /var/log/mysql/* rw,
     /var/run/mysqld/mysqld.pid w,
     /var/run/mysqld/mysqld.sock w,
     /home/sites/default/mysql/ rw,
     /home/sites/default/mysql/* rw,
   
     /sys/devices/system/cpu/ r,
   }

   The two lines in bold show what I added to the configuation. The first line gives read and write access to the directory itself while the second gives read and write access to the files contained in the directory.

2. After saving the configuration changes, I simply needed to restart the AppArmor daemon. I did this with the following command:

   [chris@rommie ~]$ sudo service apparmor restart
    * Reloading AppArmor profiles
   Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox

It is popular to use ul and li elements float them and set them to width:auto in CSS in order to create a horizontal list of self-sizing boxes. These can easily be used to create horizontal navigation or a listing of tabs, and it works very well. However, there is one caveat; given the right mix of CSS this solution doesn’t work properly in IE 6.

To create this scenario, we can simply use something like the following:

<style type="text/css">
    ul {
        height: 30px;
        overflow: hidden;
    }
    ul li {
        float: left;
        width: auto;
    }
    ul li a {
        display: block;
        height: 30px;
    }
</style>
<ul>
    <li><a href="#">Link 1</a></li>
    <li><a href="#">Link 2</a></li>
</ul>

This will show the problem in IE 6 nicely. The problem is that IE 6 interprets this mix of CSS and decides that each li element should actually expand out to 100% width.

I’ll explain how to fix this issue and provide and example page so you can easily play around with the HTML and CSS yourself.

Fix #1

A quick way to tame the IE 6 beast is to give the offending element a width of 0. Counter to intuition, this won’t force the element to an infinitely-small width; rather, it will force IE 6 to automatically-size the width of the element. However, this has an immediate problem, all other browsers will see this width of 0 for what it really is and render nothing for that element since, well, it has a width of 0.

There are a few different ways to correct this:

1. We can use a hack to introduce the width 0 command to IE 6 without having the other browsers take notice. This works and can be implemented by using _width:0 to specifically target IE 6. For example:

   #nav ul li {
       width: auto;
       _width: 0;
       float: left;
   }

2. Since using a hack isn’t always preferable, another option is to selectively-load a CSS document that adds the IE 6-only behavior. In the HTML document, you first load the standard stylesheet followed by the IE 6-specific stylesheet:

   <link rel="stylesheet" href="/css/style.css" type="text/css" media="screen" />
   <!--[if lt IE 7]>
       <link rel="stylesheet" href="/css/lt-ie7.css" type="text/css" media="screen" />
   <![endif]-->

   In the IE 6 stylesheet, add the width:0 style:

   #nav ul li {
       width: 0;
   }

3. We can use CSS selectors that are ignored by IE 6. This doesn’t use a hack and also avoids using a separate stylesheet.

   #nav ul li {
       width: 0;
       float: left;
   }
   #nav ul > li {
       width: auto;
   }

Each of these methods work nicely, however, after some additional testing, a new limitation becomes clear. For some reason, IE 6 now decides that only one word should be permitted in each box. Basically, it seems to word-wrap all additional words, effectively cutting them off. Thus the need for another fix.

Fix #2

The solution to preventing IE 6 from truncating each element is simple: prevent word wrapping. This is easily done using the white-space:nowrap CSS instruction.

Using the third example above, we can change it to the following to apply this next fix:

#nav ul li {
    width: 0;
    float: left;
    white-space: nowrap;
}
#nav ul > li {
    width: auto;
}

Example Page

I built an example page that shows what is actually occurring during each step of this process and shows how each fix improves the rendering in IE 6. The final example renders as it should.

Here is a screenshot that shows how it renders in IE 6:

Example Rendering in IE 6

Today I  have yet another entry on HTML and CSS. Today it is how to vertically center content in HTML using CSS.

You’d think that there would be a standard definition of how to vertically center any content by now, but there isn’t. There are a variety of methods out there that do this. I frequently see people using the line-height CSS property to vertically center content. While this appears to work, it isn’t very flexible, only works properly if there is only one line of text, and doesn’t work in all situations.

I found Yuhu’s Definitive Solution with Unknown Height which looks great, works properly with all major browsers, doesn’t have the limitations I’ve seen in other solutions, and is quite simple to implement. Basically all you have to do is have three divs wrapped around the content you wish to vertically center and use specific styling for those divs.

The following code is what does the magic. Replace the comment with the content to be vertically centered, change the height to match the vertical height of the container, and you’re set.

<div style="display:table; height:400px; #position:relative;">
    <div style="#position:absolute; #top:50%; display:table-cell;
vertical-align:middle;">
        <div style="#position:relative; #top:-50%">
            <!-- content to be centered -->
        </div>
    </div>
</div>

I built a quick example document that shows how I applied the rules via a style block in the head to keep the HTML clean.

As with my taming HTML lists fix, I tested this successfully on the following browsers:

• OS X
  • Firefox 3.5
  • Safari 4
• Ubuntu (Linux)
  • Firefox 3.5
  • Google Chrome 4
  • Konqueror 4.2
  • Midori 0.1.2
  • Opera 10
• Windows
  • Firefox 3.5
  • Google Chrome 4
  • Internet Explorer 6, 7, and 8
  • Safari 4

Thank you Yuhu for the great solution.

I recently tutored a friend in C coding. Since I hadn’t worked with C in at least 8 years, I really needed to have some references to rely on for syntax and other specifics. Fortunately, there are some easy man pages that can be installed in Ubuntu that offer helpful information that I was able to use to help refresh my memory.

These man pages are easily installed by installing the manpages-dev package. You can install this package via Synaptic or directly on the command line. I like the command line method personally, so I ran sudo apt-get install manpages-dev from the command line to quickly install the package.

After installing the package, I’m able to access man pages for functions such as printf, opendir, and putc. For each function, it shows the valid syntax as well as what library is required to make use of the function.

The information isn’t limited to functions as you can also access information on the libraries, such as stdio or string.

To access any of this information, simply run man [function or library name] such as man stdio.

This package isn’t limited to C functions/libraries. It is a general use Linux development suite of man pages. For a full list of what is installed, check out the file list.

Anyone that works with HTML and CSS will tell you that positioning things exactly where you want them to be is often times difficult. If you want to position something somewhere vertically, it becomes even worse.

I just finished working on a theme where I needed to force the footer of the layout to the very bottom of the page. While logically putting the footer after all the other content is easy, making it sit at the very bottom of the page even when the content doesn’t take up enough space to push it down there is quite difficult.

After struggling with getting this right for a couple of hours, I finally found a site that has done all the hard work for me. CSS Sticky Footer is the site that saved my sanity.

CSS Sticky Footer provides a solution that sticks the footer to the bottom of the page in a cross-browser compliant manner. The site reports, and I can confirm, that it works with Internet Explorer 6 through Internet Explorer 8,  Firefox, Google Chrome, Safari, Opera, and Konqueror.

Since the implementation could change, I recommend that you visit the site to get details; however, just in case something happens to the site, I’m going to add the solution here as well.

HTML

<div id="wrap">
    <div id="main" class="clearfix">
        <!-- non-footer content -->
    </div>
</div>

<div id="footer">
    <!-- footer content -->
</div>

CSS

/*
Sticky Footer Solution
by Steve Hatcher

http://stever.ca

http://www.cssstickyfooter.com

*/

* {
    margin: 0;
    padding: 0;
}

/* must declare 0 margins on everything, also for main layout components
use padding, not vertical margins (top and bottom) to add spacing, else
those margins get added to total height and your footer gets pushed down
a bit more, creating vertical scroll bars in the browser */

html, body, #wrap {
    height: 100%;
}

body > #wrap {
    height: auto;
    min-height: 100%;
}

#main {
    padding-bottom: 150px;  /* must be same height as the footer */
}

#footer {
    position: relative;
    margin-top: -150px;  /* negative value of footer height */
    height: 150px;
    clear: both;
} 

/* CLEAR FIX */
.clearfix:after {
    content: ".";
    display: block;
    height: 0;
    clear: both;
    visibility: hidden;
}
.clearfix {
    display: inline-block;
}
/* Hides from IE-mac \*/
* html .clearfix {
    height: 1%;
}
.clearfix {
    display: block;
}
/* End hide from IE-mac */

Sample

I have a sample page available to see this in action.

Many thanks to Steve Hatcher who made my job a lot easier.

Update

Someone reported that they have a roughly 45 pixel white gap at the bottom of footer of the sample and that they saw this on Firefox 3.5.3 on Vista. I’ve tested this on the exact same OS and browser, and I don’t see it. I’ve tested this on a huge variety of platforms, browsers, and browser versions, and I can’t see the gap. Does anyone else see any odd rendering?

It seems that every browser rendering engine has a completely different way of rendering lists. I recently had the frustrating job of getting them all to play nicely together.

The CSS I ended up using is quite simple and works across all the browsers I tested (list at the bottom).

This is the magic bit of CSS:

ul, ol {
    list-style-position: outside;
    margin: 0 0 0 15px;
    padding: 0;
}
ol {
    margin-left: 20px;
    *margin-left: 24px; /* targeted IE 6, 7 fix */
}
li {
    margin: 0;
    padding: 0;
}

This CSS forces all the browsers to play by the same rules. The end results are nice and clean.

The left margins are necessary to get all the browsers to not clip part of the bullet/number; however, you can change this left margin on ul/ol elements contained within the primary ul/ol if you need to adjust the indentation of each sub-list.

Each browser that I tested rendered the same thing, albeit with slightly different bullets or padding in front of the number.

The following are the browsers I tested:

• OS X
  • Firefox 3.5
  • Safari 4
• Ubuntu (Linux)
  • Firefox 3.5
  • Google Chrome 4
  • Konqueror 4.2
  • Midori 0.1.2
  • Opera 10
• Windows
  • Firefox 3.5
  • Google Chrome 4
  • Internet Explorer 6, 7, and 8
  • Safari 4

I had fun writing about how I work with Git yesterday. I thought I’d continue on that thread.

I have a solid set of code libraries that I’ve written that latch into the WordPress themes we produce at iThemes. Each time code is duplicated across different repositories, I break that code out and make it into a separate repository. I then link it back into the project as a submodule. This makes it extremely-easy to keep duplicated code across numerous repositories updated with little or no fuss.

After cloning a repository, simply run git submodule init followed by git submodule update in order to initialize all the submodules and update their container folder with the content of the submodule’s repository. For a long time, this is exactly what I did when I would clone a theme repository to start working on it. However, this quickly wasn’t enough.

The problem happened as soon as I added a submodule to a repository that was also a submodule of other repositories. Doing the submodule init and update process wouldn’t do everything I needed in this case as there would be submodules in some subfolder that haven’t been set up.

I didn’t want to get into a habit of always switching to other directories and doing the submodule processes there as well since I 1) knew that I would forget all-too-often, thus wasting my time, and 2) knew that this would not be the last time that a submodule had submodules. Heck, there is even the possibility that I’ll have a submodule that has a submodule that has a submodule. It was immediately clear that I needed a script to do all this dirty work for me. The rest of this post will be about the script I created.

The Script

First, I’ll share the script itself. If you are interested in how it works, continue reading.

git-submodule-recursive-update (right-click > “Save Link As…” to download)

The script is written in Perl and should work on most systems. I’ve only tested it on Linux and OS X, so please let me know your results if you try out on Windows.

#!/usr/bin/perl

use strict;
use Cwd;

init_and_update();

exit;

sub init_and_update
{
    my $start_path = cwd();

    my %paths;
    my $updated;

    do
    {
        my $data = `find . -name '.gitmodules'`;
        chomp($data);

        $data =~ s/\/\.gitmodules//g;

        foreach my $path (split(/\n/, $data))
        {
            $paths{$path} = '' if($paths{$path} eq '');
        }

        $updated = 0;

        foreach my $path (sort keys %paths)
        {
            if($paths{$path} eq '')
            {
                chdir($path);
                `git submodule init 2>&1`;
                `git submodule update 2>&1`;
                chdir($start_path);

                if($ARGV[0] eq '--remove-gitmodules')
                {
                    unlink("$path/.gitmodules");
                }

                $paths{$path} = 1;

                $updated++;
            }
        }
    } while($updated);
}

The Description

The functionality should look very straight-forward to anyone that knows Perl.

1. I store the current directory in the $start_path variable in order to always know where home is.
2. I start a wrapper loop that keeps running until all the possible submodules are initialized and updated.
3. Using the find command, I look for all the instances of .gitmodules and store the results in $data. The .gitmodules file exists if a repo has submodules.
4. I remove all the .gitmodules file references from the $data to leave just the paths.
5. I split the paths into an array and initialize the %paths hash to have a blank value for new paths (stored in the key). Setting this value to blank will flag the following loop that the submodules in that path have not been set up yet.
6. I create a tracker variable, $updated, to check if anything happened in the loop.
7. I then loop through the %paths hash to work on each path. If the path’s hash value is blank, I process that path.
8. I cd into the repo path, init and update the submodules, and switch back to the starting folder.
9. If the script is called with the optional --remove-gitmodules argument, I remove the .gitmodules folder while I’m focused on that folder. I use this for other automation scripts, so it may or may not be of value to you.
10. I then set the path’s hash value to 1 to flag it as done.
11. Closing out the loop, I update the $updated variable to show that something was updated in this pass.
12. Finishing up the do loop towards the top, I have while($updated). Basically, as long as something was updated in the core update loop, I’ll run everything again. This means that the loop will keep running until it didn’t find anything else that needed to be updated. When that point is reached, the main loop ends, and the script is finished.

I know that there are a number of things I could have done to make for a much more brief, compact script, but I was going to quick production with solid functionality, not brevity. In addition, there are unnecessary elements such as incrementing the $updated variable rather than just setting it to some value. I thought might want to know how many things were updated at some point, so I left it as a counter.

If you found this script helpful, please leave a comment. The more interest these Git-related posts receive, the more motivated I’ll be to share other processes, developments I’ve made to make working Git easier.

All of the WordPress themes that I work on for iThemes are managed as Git repositories. Recently, we moved past the 100 repositories mark. That’s a lot of repositories to manage, and unfortunately, too many of those repositories contain duplicated information.

Later on, I might delve into how we use Git to manage our theme repos. For today, however, I’d like to focus on how I quickly and easily pushed up changes to more than a dozen repos in a single, albeit long, Bash command.

I had finished making updates to 16 Flexx repos, and I needed to push all of those changes up. Since I had multiple working repos in that folder, I was lucky that each of these repos began with the text “Flexx”. Also, since they are all part of the same series and need to keep the same version number, that simplified the tagging as all could be tagged as 2.5.0.

Given this information, I simply ran the following command from the directory that contained all the repository directories:

There’s a lot going on here, so I’ll break it up and explain what I’m doing.

This is basically a compound command. Bash’s for command is being used to step through the results of ls|grep Flexx. Each result will be stored to the variable i which can be referred to with $i.

In other words, I’m going to loop through each directory that contains the text “Flexx” (technically, it isn’t limited to just directories, but I don’t have any files containing “Flexx”, so I’m safe). For each iteration of the loop, the variable $i will contain the name of the folder I’m interested in.

The most important bit here is do. do simply begins the functional part of the loop and could be followed by any command that I wanted to start the loop with.

The echo command isn’t technically necessary. I simply have it there so that I can better determine what output belongs to which repository.

This is a very important command. It changes the directory to the repository I wish to run commands on.

This is the command that actually does what I want to do in each repo directory. This adds all the modified files, commits them with a message of “2.5.0″, pushes the changes to the remote repository, creates a new tag of 2.5.0, and pushes up the new tag.

I have all of these commands chained together with && so that if one command fails, the other ones won’t run. This prevents tagging in the event that the repository couldn’t be committed or pushed.

It’s a small command but necessary. This switches back to the main directory that holds all the repos, thus returning us back to a state that the next loop iteration can work with.

As with the other echo command, this simply allows me to keep track of what is going on more easily.

The done command finishes out the loop iteration.

I hope that by sharing this you can gain a bit of insight into how I work with repositories while also learning more about how you can do things with Bash.

I’ve spent a little more than a month working with Git now. I can honestly say that while there are many things that I like about Git, there are just as many things that I personally find to be a pain in the butt.

Submodules specifically have managed to be a thorn in my side on many occasions. While the concept of submodules is simple, figuring out how to actually work with them can be a chore. I say “figuring out” because not everything about working with submodules is well documented. I’ll cover two of the more difficult things to figure out: removing and updating submodules from your repository.

What are Submodules?

The concept of submodules is brilliant. It essentially allows you to attach an external repository inside another repository at a specific path. In order to illustrate the value of submodules, it will probably be helpful for me to explain how I am using them.

My profession is working with WordPress themes. Basically, I develop feature enhancements to the themes. I develop the code for these enhancements in modules that are completely contained in their own folder. This allows for the code to be easily added to other themes and also simplifies code updates/improvements as the code for specific features is consistent across all the themes that use that specific module.

Each theme that we produce is kept in its own Git repository. In addition, I’ve created a separate repository for each one of these feature modules. Rather than actually putting the feature module code directly into the theme repositories, I simply add the needed feature module repositories as submodules.

For example, we have a theme called FlexxBold. FlexxBold currently includes a total of seven submodules: billboard, contact-page-plugin, featured-images, feedburner-widget, file-utility, flexx-layout-editor, and tutorials. Since I’m using submodules, the code can be pulled directly from the relevant submodule repositories rather than requiring me to manually update each individual theme repository.

As I mentioned before, not everything in Git is easy to work with. There are four main functions you will need to understand in order to work with Git submodules. In order, you will need to know how to add, make use of, remove, and update submodules. I’ll cover each of those uses below.

Adding Submodules to a Git Repository

Fortunately, adding a submodule to a git repository is actually quite simple. For example, if I’m in the repository working directory of a new theme called SampleTheme and need to add the billboard repository to the path lib/billboard, I can do so with the following command:

There are three main parts to this command:

• git submodule add – This simply tells Git that we are adding a submodule. This syntax will always remain the same.
• git@mygithost:billboard – This is the external repository that is to be added as a submodule. The exact syntax will vary depending on the setup of the Git repository you are connecting to. You need to ensure that you have the ability to clone the given repository.
• lib/billboard – This is the path where the submodule repository will be added to the main repository.

Let’s check to see how the repository is doing.

Notice how the supplied path was created and added to the changes to be committed. In addition, a new file called .gitmodules was created. This new file contains the details we supplied about the new submodule. Out of curiosity, let’s check out the contents of that new file:

Being able to modify this file later will come in handy later.

All that is left to do now is to commit the changes and then push the commit to a remote system if necessary.

Using Submodules

Having submodules in a repository is great and all, but if I look in my repository, all I have is an empty folder rather than the actual contents of the submodule’s repository. In order to fill in the submodule’s path with the files from the external repository, you must first initialize the submodules and then update them.

First, we need to initialize the submodule(s). We can do that with the following command:

Then we need to run the update in order to pull down the files.

Looking in the lib/billboard directory now shows a nice listing of the needed files.

Removing Submodules

What happens if we need to remove a submodule? Maybe I made a mistake. It could also be that the design of the project has changed, and the submodules need to change with it. No problem, I’ll simply run “git submodule rm [submodule path]” and everything will be great, right?

Unfortunately, this is wrong. Git does not have a built in way to remove submodules. Hopefully this will be resolved in the future, because we now have to do submodule removal manually.

Sticking with the example, we’ll remove the lib/billboard module from SampleTheme. All the instructions will be run from the working directory of the SampleTheme repository. In order, we need to do the following:

1. Remove the submodule’s entry in the .gitmodules file.Since lib/billboard is the only submodule in the SampleTheme repository, we can simply remove the file entirely by running “git rm lib/billboard”.If lib/billboard isn’t the only submodule, the .gitmodules file will have to be modified by hand. Open it up in vi, or your favorite text editory, and remove the three lines relevant to the submodule being removed. In this case, these lines will be removed:
   [submodule "lib/billboard"]
   path = lib/billboard
   url = git@mygithost:billboard
2. Remove the submodule’s entry in the .git/config. This step isn’t strictly necessary, but it does keep your config file tidy and will help prevent problems in the future.The submodule’s entry in .git/config will only be present if you’ve run “git submodule init” on the repository. If you haven’t, you can skip this step.In this example, the following lines will be removed:
   [submodule "billboard"]
   url = git@mygithost:billboard
3. Remove the path created for the submodule. This one is easy. Simply run “git rm –cached [plugin path]“. In this example, I will run “git rm –cached lib/billboard“.As I’ve seen noted elsewhere, do not put a trailing slash as the command will fail. For example, if I run “git rm –cached lib/billboard/“, I get an error: “fatal: pathspec ‘lib/billboard/’ did not match any files“.

Updating Submodules

There is an aspect about submodules that some may not realize when first working with Git submodules. When you add the submodule, the most recent commit of the submodule is stored in the main repository’s index. That means that as the code in the submodule’s repository updates, the same code will still be pulled on the repositories relying on the submodule.

This makes a lot of sense when you consider how your code will have been tested and verified (or at least should be) against a specific version of the submodule code, but the main repository’s code may not work well with new submodule updates before the changes are tested.

Unfortunately, like removing submodules, Git does not make it clear how to update a submodule to a later commit. Fortunately though, it’s not that tough.

1. Initialize the repository’s submodules by running “git submodule init” followed by “git submodule update“.
2. Change into the submodule’s directory. In this example, “cd lib/billboard“.
3. The submodule repositories added by “git submodule update” are  “headless”. This means that they aren’t on a current branch.To fix this, we simply need to switch to a branch. In this example, that would be the master branch. We switch with the following command: “git checkout master“.
4. Next, we simply need to update the repository to the latest checkout. We can do that with a pull: “git pull“.
5. Now switch back to the root working directory of the repository. In our example, we are two directories in, so we run “cd ../..“.
6. Everything is now ready to be commit and pushed back in (if there is a remote repository to push to that is). If you run “git status“, you’ll notice that the path to the submodule is listed as modified. This is what you should expect to see. Simply add the path to be commit and do a commit. When you do the commit, the index will update the commit string for the submodule.

Closing Thoughts

I’ve learned a lot in my short time with Git. Expect to see more details about working with Git in the future. I have a series of pitfalls I’ve discovered that I should organize together and post about. I’ve also created some really slick scripts to help me automate numerous things when working with the repositories that I’d like to share.

If there is anything specfic you’d like to know about Git, please add a comment or contact me.

I recently worked on a project where I had to sort a set of rows returned from a MySQL query. The problem is that most of the data in the field being sorted is numeric yet the field type is varchar since some of the entries contained characters.

The reason that this is a problem is that MySQL sorts character fields using a method that will produce undesirable results with numeric data. For example, sorting 4, 10, and 50 as character data produces 10, 4, and 50. In most applications, this is highly undesirable.

The solution to this is to force a sorting order that is commonly referred to as a natural sort. Natural sort is just a term that refers to how humans would commonly sort a set of information (numbers as numbers and non-numeric characters alphabetically). Fortunately, this isn’t difficult to achieve in MySQL.

To further illustrate the problem, here is a simple table description:

> DESC SampleData;



Field
Type


data_char 
varchar(5)

I filled up the table with sample data. The following example query and resulting data shows the problem clearly:

> SELECT * FROM SampleData ORDER BY data_char;



data_char


10


11


120


21


3


a1

As you can see, the results aren’t exactly usable. If we simply modify the order by declaration slightly (add “+0″ to the order by field), you can force MySQL to sort the field naturally.

> SELECT * FROM SampleData ORDER BY data_char+0;



data_char


3


10


11


21


120


a1

There you have it. To force a natural sort, just add a 0 onto the field you wish to be naturally sorted.