On Fri, November 17, 2006 01:38, Kevin Lambert wrote:
> I have a Fedora Linux box that I just upgraded from FC3 to FC6. This code
> worked fine under FC3 (it would show me all of the times in the "items"
> database. The code is at the end of the email. Under FC6 I am receiving
> a
> pqxx::sql_error message which has my select statement in it. If I do that
> select statement from psql it works fine. Any ideas?
Well, lots of variables there (postgres version, libpq version, libpqxx
version, possible changes in setup, and so on) so we may have to cull
those down a bit. Let's look at the code first, though:
> Try {
Ahem. :)
> conn = new connection("dbname=testdb user=postgres");
>
> work Xaction(*conn, "DemoTransaction");
It's at least possible that you're running into a bug with handling of
upper-case characters in names. It shouldn't be a problem with
transactions, but you could try using an all-lower-case name just to be
sure that this isn't related to the problem.
> result R = Xaction.exec("SELECT * from items;");
This is where it hurts, right?
The semicolon isn't really right there. It *shouldn't* cause any
problems, but who knows, it may. The semicolon is used as a separator
between queries, so it's almost like you're issuing two queries at once
here: first a SELECT and then an empty one.
> for (result::size_type i=0; i != R.size(); ++I ) {
> String itemname = R[i]["itemname"]'
It would help if you could post code that really does reproduce the
problem. This line wouldn't even compile because of the extra quote.
> Int quantity, productId;
> R[i]["quantity"].to(quantity);
> R[i]["productid"].to(productId);
There are no "String" and "Int" types in C++, so are these typedefs for
std::string and int?
> }
> } catch(pqxx::sql_error sqlE) {
> }
This really doesn't have anything to do with the problem, but always try
to catch *references* to exception objects:
} catch (pqxx::sql_error &sqlE) {
If you leave out the reference, an exception object of a type derived from
the one you're catching may get "sliced." In this case, that means that
if the exception is an object of some child class of sql_error, what you
will get is a new object of type sql_error. Some information can be lost,
which is bad, but things get even worse when virtual functions are
involved.
Jeroen
_______________________________________________
Libpqxx-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
