James Vanns wrote:
> data returned from an SSQL execution is er, 0 or blank!
Can you show this by modifying one of the examples? There's a similar
one to your code, examples/ssqls4.cpp, which does work.
> sql_create_2 (hdb_module_t, 2, 0, sql_varchar, name,
> sql_smallint_unsigned, id)
This declaration seems dubious.
set<> uses less-than comparison to decide whether a new member is unique
before inserting it into the set, and to determine where in the set it
goes. You're saying, here, that either the name or the name and the ID
together have to be different in order to get into the set. Note that
it doesn't test 'id' unless the two 'name' fields are different. It
also means that in order to look up a value in the set, you have to
provide both name and id. Why use a set<> if you're not looking up
records by a subset of the fields in the record?
I wonder if you want a map<string, unsigned short> (or vice versa)
instead: a way to look up a name from an id or vice versa without making
a round-trip to the DB. As explained elsewhere in a recent epic thread,
MySQL++ doesn't have a way to populate a map<> automatically, but it's
easy to build the mechanism yourself using Query::for_each().
If map<> isn't right, and either name or id is the unique key you need,
the first number should be 1, and the second probably 2, not 0. Note
that MySQL++ v3 lets you declare the SSQLS members in any order now,
you're not stuck with declaring them in the same order as the DB table.