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 up
data 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!
