FAQ.rst 5.1 KB

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