Joe Hudson wrote:
>
> with you on the PIC microcontrollers :) well the include path for mysql.h is
> set in the project settings.
> and that is the first error... Seems Eclipse was very confusingly displayng
> errors for other projects in my build group,. :)
Dunno what to tell you, then. I don't think anything has changed in the
way we #include MySQL C API headers in quite a while.
> would
> defining MYSQLPP_SSQLS_NO_STATICS globally and just calling:
>
> MYSQLPP_SSQLS_EXPAND(<SSQLS name>)
>
> once for each struct in a .cpp file for the header that defines the SSQLS's
> be a reasonable solution to where there are lots of modules that use the
> same SSQLS's?
No. MYSQLPP_SSQLS_EXPAND isn't called that way, and replicating the way
it *is* called would evaporate much of the advantage of SSQLSes.
You can do something like this instead in the .h file:
#if !defined(EXPAND_MYSTRUCT)
#define MYSQLPP_SSQLS_NO_STATICS
#endif
And then #define EXPAND_MYSTRUCT before #including that header in the
one module that you nominate as owning the SSQLS.
> I have lots (a few thousand) of tables with the same
> structure, but I want them as seperate tables because each could contain a
> lot of data and they are for seperate real world things that I want to keep
> seperate in the DB. I just want a neat and convenient way of using the same
> SSQLS type to manipulate different tables with the same structure. Is that
> weird?
It sounds to me like you're trying to impose an OO structure on top of a
relational database, always a tarpit.
Maybe you should do without SSQLS altogether, and populate data
structures you define from the lower-level Row data instead:
struct MyGenericThingy {
int a;
string b;
MyGenericThingy(mysqlpp::Row& row) :
a(row["a"]),
b(row["b"])
{
}
};
