# 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.

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
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.
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 platforms does it work on?

MySQL++ should work on any platform that has a C++98 or newer compiler and the MySQL C API development files. MySQL++ does use some C99/TR1 features that didn’t make it into C++ until C++11 or C++14, but these are optional, so it still works with C++98 compilers.
MySQL++ should work on any platform that has a C++98 or newer compiler and the MySQL C API development files. MySQL++ does optionally use some C++11 and C++14 features, but their presence is either autodetected at build time, or you have to go out of your way to enable them.

In practice, MySQL++ works best on the platforms that get the most attention. This means mass-market operating systems on common hardware, and the default tool chain for the platform. There are FAQ items for most common platforms below; if your platform isn’t addressed and it’s outside the mainstream or is older than about 2003, the chance of it working out of the box are low. We’re happy to discuss porting on the [forum], but be prepared to do most of the work yourself; if MySQL++ hasn’t been ported to your system already, there’s usually a pretty good reason why not.
In practice, MySQL++ works best on the platforms that get the most attention. This means mass-market operating systems on common hardware, and the default tool chain for the platform. There are FAQ items for most common platforms below; if your platform isn’t addressed and it’s outside the mainstream or it's older than about ten years, the chance of MySQL++ working out of the box drops. We’re happy to discuss porting on the [forum], but be prepared to do most of the work yourself; if MySQL++ hasn’t been ported to your system already, there’s usually a pretty good reason why not.

If you use a different platform and it isn’t mentioned in the subsequent FAQ items, probably little is known about it. If it builds out of the box, we’d appreciate it if you’d send a report or a patch to the [forum]. We will support any platform that gets enough interest from the users.

[forum]: /forum


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

Occasionally a version of MinGW comes out that breaks MySQL++, but there has always been a usable workaround.


## <a name="borland"></a>Will it build under C++Builder?

It can be made to work, mostly.

The last time it was tried, the [Specialized SQL Structures](doc/html/userman/ssqls.html) feature didn’t work right out of the box due to a compiler limitation. A full discussion of the problem and possible workarounds is in [this mailing list message](http://lists.mysql.com/plusplus/4307).
The last time it was tried, the [Specialized SQL Structures](doc/html/userman/ssqls.html) feature didn’t work right out of the box due to a compiler limitation. A full discussion of the problem and possible workarounds is in [this old mailing list message](http://lists.mysql.com/plusplus/4307).

That was back in the Borland days, so if you’ve verified functionality under one of the newer Embarcadero releases, we’d appreciate a report on the mailing list.
That was back in the Borland days, so if you’ve verified functionality under one of the newer Embarcadero releases, we’d appreciate a report on the [forum].


## <a name="hownottobuild"></a>`g++ simple1.cpp -o simple1`?

No!

You’re probably missing a `-I` flag for the MySQL++ headers, and you’re certainly missing [correct link flags](#linkerrors).

If you’re getting a report from a memory debugger about a leak, most likely you’re seeing memory that the MySQL C API library allocates for its own internal purposes. MySQL++ is built atop this library, so it can look like it’s MySQL++ leaking the memory. This underlying C library automatically allocates multiple blocks of memory in ways that are more or less outside MySQL++’s control. If you feel you must plug these leaks, it is up to your code to call the relevant C API functions.

These “leaks” are all harmless in practice for most programs. A typical program using MySQL++ needs database access for its entire effective run time, and the size of the leak doesn’t increase over run time if you follow the instructions in the [threads chapter](doc/html/userman/threads.html) of the [User Manual](doc/html/userman/). The OS automatically frees this memory when your program exits.

That said, it’s annoying to see leak reports in a memory debugger, particularly if leak checking is a regular part of your build and test process. You can placate the memory debugger by calling `Connection::thread_end()` from each thread that uses a database
connection when that thread finishes using the database. In addition, after the last bit of code that uses MySQL++ stops, you need to call the MySQL C API function mysql_library_end()`. If you’re using a `ConnectionPool`, you might put this last call in the destructor, since the pool object is typically the last MySQL++ object to be destroyed.

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 retrieved? 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.
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 retrieved? Until you can establish this link, it’s premature to post to the MySQL++ [forum] 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.


## <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.
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 [forum] with a detailed failure report.


## <a name="bugreport"></a>I’m sure I’ve found a bug. How do I submit a report?

We’ll want some code that demonstrates the bug. No doubt you’d rather not send us a copy of your database to demonstrate the problem, and to be frank, we don’t want your database, either. The best thing is to modify one of the MySQL++ examples so that it reproduces the problem you’re seeing. This lets the people that can help you reproduce the problem on their machines, without needing your database.

Once you have your problem boiled down to a simple example, send the source code to the mailing list along with a detailed report. We want to know what you expect the program to do, and what it actually does on your machine. Keep in mind, programs often behave differently on different systems. As a programmer yourself, you know what it is like to deal with vague user bug reports. Give us the sort of error report you’d like to receive for your own programs.
Once you have your problem boiled down to a simple example, send the source code to the [forum] along with a detailed report. We want to know what you expect the program to do, and what it actually does on your machine. Keep in mind, programs often behave differently on different systems. As a programmer yourself, you know what it is like to deal with vague user bug reports. Give us the sort of error report you’d like to receive for your own programs.

There's also the [ticket tracker](/ticket), but we prefer that you send the report to the mailing list for discussion first. Especially do not use the ticket tracker if you just need help *using* MySQL++.
There's also the [ticket tracker](/ticket), but we prefer that you send the report to the [forum] for discussion first. Especially do not use the ticket tracker if you just need help *using* MySQL++.


## <a name="patches"></a>How do I submit a change to MySQL++?

This is covered in detail in the library's [hacker's guide](/doc/trunk/HACKERS.md).

But in brief: we want the patch in unified diff format, made against either the latest release of MySQL++ or (preferably) against [the trunk of the Fossil repository](/timeline?r=trunk). You can send it either to the [mailing list](http://lists.mysql.com/plusplus/), or to [the ticket tracker](/ticket). We prefer that you only use the ticket tracker for patches that are so trivial or obvious that they won’t need discussion.
But in brief: we want the patch in unified diff format, made against either the latest release of MySQL++ or (preferably) against [the trunk of the Fossil repository](/timeline?r=trunk). You can send it either to the [forum] or to [the ticket tracker](/ticket). We prefer that you only use the ticket tracker for patches that are so trivial or obvious that they won’t need discussion.

When a patch is rejected, the most common reason is that it breaks the library’s binary interface (ABI), so that an old program can’t link to the changed library without recompiling. We only make such changes at major version transitions. These transitions are rare, and we can’t even promise that there will ever be another one, much less when it will occur. If you have a choice of two ways to get your desired effect and one of them doesn’t break the ABI, it will increase the chances that we accept your patch if you do it that way.

<p style="height: 50em">&nbsp;</p>