Quoting Jeff MacDonald <jam@xxxxxxxxxxxxxxxxxxxx>:
ok.. in all of your tests you have been connecting across your local network, which takes the shaw devices out of the equation. if you are able to connect with pgAdmin3 via ip address (and from your message it seems that you are), my guess is that pgsql is accepting connections via tcp/ip. since you are attempting to connect to pgsql on your local network from your web server (which is hosted elsewhere) and it times out, this tells me that there is a device in the middle someplace that is firewalling the packets. you are *unlikely* to convince shaw to make firewall changes (if that is what is happening) so you can do this. ok.. now the hopefully easy question :): why are you trying to set things up this way? regards, J -- Jeff MacDonald Zoid Technologies, http://zoidtechnologies.com/
Fair question. I'll tell you what I'm trying to do, and perhaps you can advise
a better solution. On my local machine I have a postpreSQL database. This database I update constantly let's say.Hosted on another machine in cyberspace is my webserver. On this machine I have
a webpage that I want to update using data from the database on my local machine. The webserver is running PHP/mySQL.Can you think of a better way? A direct connection querying the database seemed
like the best solution for this. I'm not sure if my web host would allow me to run a postgreSQL server on it as well. So, ftp'ing the database up once a day say may not be an option.One of my original thoughts (before I understood the systems at all) was that I
would have to have a "cron" job running on my local machine that would ftp updata as it was collected. The webserver, the next time a php script ran, would check for new data, parse it, add it to the mySQL database on the webserver, and
then run the scripts using the data from the webserver's mySQL server. Sounds horrid!