I'm going to apologize ahead of time for the length of this post. I just want to be sure I didn't leave any info out.

I have an application which uses django's ORM outside of a django app, which uses "syncdb" by calling `call_command('syncdb')` directly (note: I'm using a virtualenv for every scenario listed below).

My unit tests in the application try to setup a "test" django database using SQLite as the backend (whereas the production environment uses MySQL).

Each time one of the unit tests runs, it calls `call_command('syncdb')` using the same test django settings throughout each test.

I am able to run these unit tests on 2 different environments (one with Windows 7/Python 2.7.3, another with Mac OS X ML/Python 2.7.2). There are no issues at all with the tests; but these are relatively clean Python installs on both.

However, when I try to run this on a RHEL server, I get the following error, when the unit tests try to run syncdb:

> 
> DatabaseError: table "my\_app\_mytable" already exists
> 
> 
> 

After a lot of frustrating googling and debugging, I (think) I've eliminated the bugs reported [here](https://code.djangoproject.com/ticket/9116) and [here](https://stackoverflow.com/questions/1283792/django-is-telling-me-table-already-exists-on-syncdb-cant-figure-out-why).

I did a lot of hacking around, and I think I have narrowed the problem down to this statement in [django's syncdb command file](https://github.com/django/django/blob/master/django/core/management/commands/syncdb.py) (as crazy as that sounds) (line 59):

```
tables = connection.introspection.table_names()

```

I setup a `pdb.set_trace()` inside django's syncdb source on both environments to take a look. Here is what I found:

(Env that works)

```
(Pdb) tables
[u'my_app_mytable', u'my_app_myothertable']

```

Seems OK there. From the looks of the syncdb file, django uses the `tables` variable to check an app's models against what's already in the database.

(Env that doesn't work)

```
(Pdb) tables
[u'm\x00y\x00_\x00a\x00p\x00p\x00_\x00m\x00y\x00t\x00a\x00', u'm\x00y\x00_\x00a\x00p\x00p\x00_\x00m\x00y\x00o\x00t\x00']

```

Unless I'm just going crazy, I think this is making the following statement in django's source return false:

```
def model_installed(model):
        opts = model._meta
        converter = connection.introspection.table_name_converter
        return not ((converter(opts.db_table) in tables) or
            (opts.auto_created and converter(opts.auto_created._meta.db_table) in tables))

```

This method is called via `filter` a few lines after that definition, and it looks like it checks to see if `converter(opts.db_table)` is in the `tables` list. I ran them manually in both environments too:

(Env that works)

```
(Pdb) opts = all_models[0][1][0]._meta
(Pdb) converter = connection.introspection.table_name_converter
(Pdb) converter(opts.db_table) in tables
True

```

As you can see I (kind of) manually ran the `model_installed` function to see what `converter(opts.db_table)` returns, and it looks like a perfectly normal string on both environments. However:

(Env that doesn't work)

```
(Pdb) opts = all_models[0][1][0]._meta
(Pdb) converter = connection.introspection.table_name_converter
(Pdb) converter(opts.db_table) in tables
False

```

So it looks like since the `tables` variable is a list of crazy-looking crud on the broken environment, that method is falsely claiming that each model's table name isn't in the database, which gives me the original error I stated at the beginning.

Just to make sure I really wasn't going nuts, I also tried manually inserting the correct list to compare:

(Env that doesn't work)

```
(Pdb) converter(opts.db_table) in [u'my_app_mytable', u'my_app_myothertable']
True

```

Do I need to recompile Python on this environment? I read the [following question](https://stackoverflow.com/questions/10253405/python-x00-filled-utf-32-string-from-cstringio) on stackoverflow, and found my broken environment was exhibiting weird behavior:

```
(myvirtualenv)[username@myserver]$ python
Python 2.7.3 (default, Apr 12 2012, 10:40:11)
[GCC 4.4.6 20110731 (Red Hat 4.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import StringIO, cStringIO, sys
>>> StringIO.StringIO(u"fubar").getvalue()
u'fubar'
>>> cStringIO.StringIO(u"fubar").getvalue()
'fubar'
>>> cStringIO.StringIO(u"\u0405\u0406").getvalue()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128)
>>> sys.maxunicode
65535
>>> sys.byteorder
'little'

```

EDIT: OK, so I looked a little bit through the django source some more, and it looks like they're getting the table list this way:

```
def get_table_list(self, cursor):
    "Returns a list of table names in the current database."
    # Skip the sqlite_sequence system table used for autoincrement key
    # generation.
    cursor.execute("""
        SELECT name FROM sqlite_master
        WHERE type='table' AND NOT name='sqlite_sequence'
        ORDER BY name""")
    return [row[0] for row in cursor.fetchall()]

```

So I connected to the sqlite file manually in the python interpreter, and ran that query:

(Env that doesn't work)

```
>>> import sqlite3
>>> conn = sqlite3.connect('/path/to/sqlite/file')
>>> curs = conn.cursor()
>>> curs.execute("""
... SELECT name FROM sqlite_master
... WHERE type='table' AND NOT name='sqlite_sequence'
... ORDER BY name""")
<sqlite3.Cursor object at 0xb7557500>
>>> curs.fetchall()
[(u'c\x00c\x00_\x00s\x00t\x00a\x00t\x00s\x00_\x00c\x00c\x00',), (u'c\x00c\x00_\x00s\x00t\x00a\x00t\x00s\x00_\x00c\x00c\x00s',)]

```

So it looks like SQLite returns a UTF16-LE string for that query. On the working environment, it returned the following:

(Env that works)

```
>>> curs.fetchall()
[(u'my_app_mytable',), (u'my_app_myothertable',)]

```

Even without an encoding defined at the top, the "working" environment doesn't seem to have any trouble interpreting my `models` file and creating the tables appropriately. Is there some SQLite default setting that is causing this? Or is git converting the file to UTF-16LE on the broken environment, and sticking with UTF-8/ASCII in the working environment?