# Frequently-Asked Questions About MySQL++

## What version of MySQL++ should I use?

If you’re writing new code, you should use the [latest stable version](/#stable).

If you have existing code currently using an older version of MySQL++, you may not want to upgrade all the way to the current version, at least not in a single step. You might want to upgrade to an [intermediate version](#oldver) first, just to get bug fixes and maybe some minor features. Then once that step is working and tested, you can think about jumping to the latest stable version.
If you have existing code currently using an older version of MySQL++, you may not want to upgrade all the way to the current version, at least not in a single step. You might want to upgrade to an [intermediate version](/#oldver) first, just to get bug fixes and maybe some minor features. Then once that step is working and tested, you can think about jumping to the latest stable version.

MySQL++ uses the standard major.minor.bug-fix version number scheme. A change in the library’s major version number denotes changes that will almost certainly require source code changes in your program. See the “[Incompatible Library Changes](doc/html/userman/breakages.html)” chapter of the user manual for details. A change in the minor version number indicates added features that don’t change existing library interfaces. If you don’t want to use those features, you should be able
to install the new library without rebuilding your program. A change in the bug-fix number indicates internal bug fixes, which don’t affect the library interface at all, so such versions are always safe to install.

We haven’t followed this discipline perfectly. The library’s binary interface [changed a few times](doc/html/userman/breakages.html#abi-1.7.18) between the epochal 1.7.9 release and the final 1.*x* release, 1.7.40. If your program uses a version in between, be prepared to change the code when upgrading. The library interface also [changed a few times](doc/html/userman/breakages.html#abi-3.0.0) early in the 3.*x* series before settling down.

## What versions of MySQL does it work with?

MySQL++ works best with MySQL version 4.1 or higher, simply because this is the oldest version that it’s regularly tested against during development.

We do most of the development against MySQL 5.1 or newer, since we don’t use older versions on our production machines. Because MySQL++ is intended for use in production environments, we also don’t test it against bleeding-edge versions of MySQL; the newest version we typically test it with is the current GA release at the time MySQL++ was released. We’re not opposed to supporting newer versions, we just don’t build test environments for these newer versions in advance of need. If you find
that MySQL++ isn’t building against a newer release of MySQL, a short [bug report](#bugreport) is usually sufficient to get it fixed.
that MySQL++ isn’t building against a newer release of MySQL, a short [bug report](/#bugreport) is usually sufficient to get it fixed.

With some work, MySQL++ may be modified to work on older versions of MySQL.


## <a name="mariadb"></a>Does it build against [MariaDB](https://mariadb.org)?

Yes. The library is only called “MySQL++” because it predates MariaDB.

If you’ve done that and still think you really have a serious memory leak — one of those “the longer it runs, the more memory it uses” sorts of leak — you need to tie it to some unit of work. Does memory go up as a function of time? number of queries issued? count of rows retreived? Until you can establish this link, it’s premature to post to the MySQL++ mailing list claiming there’s a leak in MySQL++. Even if you can establish such a link, it’s far more likely that you’re not releasing the MySQL++ objects you allocate than MySQL++ itself failing to release memory.


## <a name="segfaults"></a>My program is crashing. Help!

The most common cause of crashes in MySQL++ is uncaught exceptions. The library throws exceptions when it detects errors, such as invalid SQL syntax, invalid login parameters, etc. Try running the example programs, since they all catch exceptions properly.

If the examples also crash and you’re using a package built for a different Linux distribution than the one you’re actually running, try rebuilding the package from [source](#source) on the target OS. A binary package is fairly closely tied to the system it is built under, so it’s possible that RPMs you build on your system will work better than those built elsewhere.
If the examples also crash and you’re using a package built for a different Linux distribution than the one you’re actually running, try rebuilding the package from [source](/#source) on the target OS. A binary package is fairly closely tied to the system it is built under, so it’s possible that RPMs you build on your system will work better than those built elsewhere.


## <a name="broken"></a>Nothing’s working at all! Is it broken?

Maybe, but have you tried running the examples? Follow the instructions in the `README-examples.txt` file. If the examples work but your program doesn’t, chances are good that the error is in your program; study the examples, and [read the manuals](/wiki?name=Documentation). If the examples also fail to work, post to the mailing list with a detailed failure report.