List:MySQL++« Previous MessageNext Message »
From:James Vanns Date:September 10 2008 5:47pm
Subject:Re: Result set count correct but each attribute is empty!
View as plain text  
Can I ask why it looks dubious? Sorry I should have mentioned that I changed that '2' from
a 1 in case that made any difference - which it didn't. I've tried it with a set and list
- both with the same (non) result.

Jim

----- Original Message -----
From: "Warren Young" <mysqlpp@stripped>
To: "MySQL++ Mailing List" <plusplus@stripped>
Sent: Wednesday, 10 September, 2008 6:38:42 PM GMT +00:00 GMT Britain, Ireland, Portugal
Subject: Re: Result set count correct but each attribute is empty!

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.

-- 
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:    http://lists.mysql.com/plusplus?unsub=1


-- 
James Vanns
Systems Programmer
Framestore CFC Ltd.
Thread
Result set count correct but each attribute is empty!James Vanns10 Sep
  • Re: Result set count correct but each attribute is empty!Warren Young10 Sep
    • Re: Result set count correct but each attribute is empty!James Vanns10 Sep
      • Re: Result set count correct but each attribute is empty!Warren Young10 Sep
Re: Result set count correct but each attribute is empty!James Vanns11 Sep
  • Re: Result set count correct but each attribute is empty!Warren Young11 Sep
Re: Result set count correct but each attribute is empty!James Vanns11 Sep
  • Re: Result set count correct but each attribute is empty!Warren Young11 Sep
Re: Result set count correct but each attribute is empty!James Vanns18 Sep
  • Re: Result set count correct but each attribute is empty!Warren Young18 Sep
    • Re: Result set count correct but each attribute is empty!James Vanns18 Sep
      • Re: Result set count correct but each attribute is empty!Warren Young18 Sep
        • Re: Result set count correct but each attribute is empty!James Vanns18 Sep
        • Re: Result set count correct but each attribute is empty!Warren Young18 Sep
    • Re: Result set count correct but each attribute is empty!James Vanns18 Sep