Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

[c16ae2]: doc / FAQ.txt Maximize Restore History

Download this file

FAQ.txt    144 lines (97 with data), 5.2 kB

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
====================================
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