On Sat, May 6, 2006 03:52, Jonathan Blitz wrote: > It seems that it did compile some of them.
Argh. I'm sorry once again that getting all this stuff to work on Windows is so hard... At least we have achieved a semblance of free 24-hour support, what with Bart and myself being 6 timezones apart. More than can be said for most commercial support offerings. Three cheers for Bart, who I know would be busy enough already without following this mailing list! > I tried to start running them and it complained that the database is > missing. That, compared to what went before, is very good news indeed! It means that now you need to give the programs a database to connect to, and tell them how to access it by setting the appropriate environment variables before running the programs (in your own code it's probably easier to pass a string of parameters when you create a connection). For the test programs, the way to do this is as follows (this is also described in the documentation): 1. If the PostgreSQL server is on a remote machine, set PGHOST to the IP address where that machine can be reached. If not, leaving PGHOST undefined should work. If it doesn't, try 127.0.0.1 (localhost). PGHOST also accepts paths to Unix-domain sockets (which live "in the filesystem" rather than "on the network"), but I'm not sure if or how that works under Windows. If PGHOST starts with a slash, it is assumed to be the location of such a local socket. 2. Set PGDATABASE to the name of a database on that server that you want to run the tests in. Best use a dedicated database for this, so the tests don't interfere with your data. On Unix-like systems at least, and probably on Windows as well, the default database is one named after the user identity you are logged in with (and the custom is to give each user his own database under the same name, to which that system user can log in without requiring a password). 3. Set PGUSER to the username you would like the test programs to use when logging into the database. Again, on Unix-like systems this defaults to your current username and it'll probably do the same on Windows. Note that of all the test programs, test000 alone does not need a database connection. So the typical symptom of not having a database to connect to is that test000 succeeds and everything else fails. If test000 fails as well, there are other problems--typically a DLL not being found. Jeroen _______________________________________________ Libpqxx-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
