| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143 |
- ====================================
- MySQLdb Frequently Asked Questions
- ====================================
- .. contents::
- ..
- Build Errors
- ------------
- ld: fatal: library -lmysqlclient_r: not found
- mysqlclient_r is the thread-safe library. It's not available on
- all platforms, or all installations, apparently. You'll need to
- reconfigure site.cfg (in MySQLdb-1.2.1 and newer) to have
- threadsafe = False.
- mysql.h: No such file or directory
- This almost always mean you don't have development packages
- installed. On some systems, C headers for various things (like MySQL)
- are distributed as a seperate package. You'll need to figure out
- what that is and install it, but often the name ends with -devel.
- Another possibility: Some older versions of mysql_config behave oddly
- and may throw quotes around some of the path names, which confused
- MySQLdb-1.2.0. 1.2.1 works around these problems. If you see things
- like -I'/usr/local/include/mysql' in your compile command, that's
- probably the issue, but it shouldn't happen any more.
- ImportError
- -----------
- ImportError: No module named _mysql
- If you see this, it's likely you did some wrong when installing
- MySQLdb; re-read (or read) README. _mysql is the low-level C module
- that interfaces with the MySQL client library.
- Various versions of MySQLdb in the past have had build issues on
- "weird" platforms; "weird" in this case means "not Linux", though
- generally there aren't problems on Unix/POSIX platforms, including
- BSDs and Mac OS X. Windows has been more problematic, in part because
- there is no `mysql_config` available in the Windows installation of
- MySQL. 1.2.1 solves most, if not all, of these problems, but you will
- still have to edit a configuration file so that the setup knows where
- to find MySQL and what libraries to include.
- ImportError: libmysqlclient_r.so.14: cannot open shared object file: No such file or directory
- The number after .so may vary, but this means you have a version of
- MySQLdb compiled against one version of MySQL, and are now trying to
- run it against a different version. The shared library version tends
- to change between major releases.
- Solution: Rebuilt MySQLdb, or get the matching version of MySQL.
- Another thing that can cause this: The MySQL libraries may not be on
- your system path.
- Solutions:
- * set the LD_LIBRARY_PATH environment variable so that it includes
- the path to the MySQL libraries.
- * set static=True in site.cfg for static linking
- * reconfigure your system so that the MySQL libraries are on the
- default loader path. In Linux, you edit /etc/ld.so.conf and run
- ldconfig. For Solaris, see `Linker and Libraries Guide
- <http://docs.sun.com/app/docs/doc/817-3677/6mj8mbtbe?a=view>`_.
- ImportError: ld.so.1: python: fatal: libmtmalloc.so.1: DF_1_NOOPEN tagged object may not be dlopen()'ed
- This is a weird one from Solaris. What does it mean? I have no idea.
- However, things like this can happen if there is some sort of a compiler
- or environment mismatch between Python and MySQL. For example, on some
- commercial systems, you might have some code compiled with their own
- compiler, and other things compiled with GCC. They don't always mesh
- together. One way to encounter this is by getting binary packages from
- different vendors.
- Solution: Rebuild Python or MySQL (or maybe both) from source.
- ImportError: dlopen(./_mysql.so, 2): Symbol not found: _sprintf$LDBLStub
- Referenced from: ./_mysql.so
- Expected in: dynamic lookup
- This is one from Mac OS X. It seems to have been a compiler mismatch,
- but this time between two different versions of GCC. It seems nearly
- every major release of GCC changes the ABI in some why, so linking
- code compiled with GCC-3.3 and GCC-4.0, for example, can be
- problematic.
- My data disappeared! (or won't go away!)
- ----------------------------------------
- Starting with 1.2.0, MySQLdb disables autocommit by default, as
- required by the DB-API standard (`PEP-249`_). If you are using InnoDB
- tables or some other type of transactional table type, you'll need
- to do connection.commit() before closing the connection, or else
- none of your changes will be written to the database.
- Conversely, you can also use connection.rollback() to throw away
- any changes you've made since the last commit.
- Important note: Some SQL statements -- specifically DDL statements
- like CREATE TABLE -- are non-transactional, so they can't be
- rolled back, and they cause pending transactions to commit.
- Other Errors
- ------------
- OperationalError: (1251, 'Client does not support authentication protocol requested by server; consider upgrading MySQL client')
- This means your server and client libraries are not the same version.
- More specifically, it probably means you have a 4.1 or newer server
- and 4.0 or older client. You can either upgrade the client side, or
- try some of the workarounds in `Password Hashing as of MySQL 4.1
- <http://dev.mysql.com/doc/refman/5.0/en/password-hashing.html>`_.
- Other Resources
- ---------------
- * Help forum. Please search before posting.
- * `Google <http://www.google.com/>`_
- * READ README!
- * Read the User's Guide
- * Read `PEP-249`_
- .. _`PEP-249`: http://www.python.org/peps/pep-0249.html
|