I think the ns_db command will work if the database cannot be connected to. At start time, nspostgres is loaded and reads it's section from the nsd.tcl file. If there is an error in that section (typo, not configured properly etc.) then nspostgres fails to load and ns_db is disabled. Paul has an error in his nsd.tcl file.
nspostgres does not to my knowledge try to connect to the database until the first sql statement you issue, so it'll start up properly even if your database isn't around. /s. > On Wednesday, December 12, 2001, at 01:16 PM, Scott Goodwin wrote: > > Take a close look at your server log where the db stuff is initialized and > > nspostgres is loaded. ns_db is disabled if nspostgres can't connect to the > > database. You should have some info there. You may need to turn on debug. > I haven't yet had the opportunity to work with the nspostgres driver. Is > it true that it will leave ns_db disabled if it can't connect to the DB at > startup? I'd like to suggest that behavior is a little drastic; I'd think > that faulty database connectivity might be recoverable (maybe the DB > server is temporarily down), and disabling ns_db prevents the AOLserver > from recovering without being restarted. Personally, I'd prefer to do > catches around my ns_db open calls, and give reasonable failure messages > until the connection succeeds. Then when the DB server comes back up, > stuff should just start working again. I know the Sybase driver works > this way -- as long as the libraries get loaded, the module is OK, and > ns_db should be available; if the DB is down, that's a separate issue. > >
