diff options
Diffstat (limited to 'MySQLdb/doc/FAQ.txt')
| -rw-r--r-- | MySQLdb/doc/FAQ.txt | 143 |
1 files changed, 0 insertions, 143 deletions
diff --git a/MySQLdb/doc/FAQ.txt b/MySQLdb/doc/FAQ.txt deleted file mode 100644 index b6a4ce9..0000000 --- a/MySQLdb/doc/FAQ.txt +++ /dev/null @@ -1,143 +0,0 @@ -==================================== - 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 - |