On Wed, December 21, 2005 01:02, Szûcs Gábor wrote: > pqxx::connection's documentation says: > The advantage of having an "immediate" connection (represented by this > class) is that errors in setting up the connection will probably occur > during construction of the connection object, rather than at some later > point further down your program. > > This is what seems to be hurt here.
At the point where you want a definite answer (either a working connection or an exception), invoke the connection's activate() method. This will work even if you're using a lazy or asynchronous connection. Also, don't bother with the reconnect() stuff. The connection class has that built in, and it will take care not to reconnect when you're in the middle of a transaction or anything like that. Just be sure to use inhibit_reactivation() if you create temp tables or other session state that will live beyond the transaction without going through special libpqxx functions. Things like session variables and cursors are taken care of automatically, of course, as long as you manage them through their special-purpose libpqxx functions. > * begin() creates a pqxx::transaction<> W. > * Connection::exec() tries to begin() if needed and W->exec(), but > receives > "Broken connection" in begin(). Code snippet and log file below. Well, according to the log you post, the backend is expecting a password and you're not supplying one in the connection string. I don't think the server can be set up to trust the system's user authentication in this case, since the client system is not the same as the server system. How will the server know that this is not, say, someone outside your building who's connecting his laptop to a rogue WiFi access point who just set up a user called gyujt to get into the database? That's just an example of course, but you'd be amazed how often this kind of back door is left wide open. > Another question: I'd like to use a unique "NORESULT" of type pqxx::result > to be returned from exec() on error. Unfortunately, `r = pqxx::result()' > wouldn't work since INSERTs return the same kind of result. What do you > think is the clearest method? INSERT will return a result with no data, but it's not quite the same as a completely empty result. This is getting eerily close to the twilight zone however: there are results with absolutely nothing in them, results with no columns and no rows but execution status information, and of course rows with metadata (including columns) but simply no rows. Internally of course, most errors will cause a result with no data but error status information to be created. In principle I guess we could make that accessible somehow. But in the end, this is exactly the kind of situation that exceptions are for. When you get an error, why not let the exception propagate upwards until it gets to a point where the problem can be handled? Jeroen _______________________________________________ Libpqxx-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
