Hi Alban
Much thanks for getting back to me!
The event file gets written to (as attached):
C:\Users\SDB\AppData\Local\Temp
I copied the contents of the /data directory to the D: drive, then changed
the folder reference in the Registry. However, after this I was able to
create tables in Navicat without any problems, until I tried to use pgAdmin
when it required my password, which I had forgotten. Then I tried to
reinstall, and started having these problems..
I'm being recommended to try running pg_dump by Thomas Kellerer, then remove
all my data folders and a reinstall. I get the feeling it is not moving my
data to the D: drive that has caused the problem, but that the Uninstall has
not cleaned this out correctly, as I moved my data to D:/../data_old to
enable Postgres to reinstall and used the installation Wizard to point to my
data location, but still get installation errors and a connection problem,
despite using the 'correct' password.
When I start pgAdmin, TaskManager shows that Postgres is running, -so I
don't think I have an unrecoverable database snapshot?
Thanks
Stephen
-----Original Message-----
From: Alban Hertroys [mailto:haramrae@gmail.com]
Sent: 31 July 2013 11:48
To: Stephen Brearley
Cc: 'Adrian Klaver'; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Postgres 9.2.4 for Windows (Vista) Dell Vostro 400,
re-installation failure PLEASE CAN SOMEONE HELP!!
On Jul 31, 2013, at 12:07, "Stephen Brearley" <mail@stephenbrearley.name>
wrote:
> Both the install and uninstall should work flawlessly. The only thing
> I can see is that I have installed the program once before, and I have
> put my data on my d: drive to separate it from the program in case of
> software problems, but I got Postgresql to correctly find my data before..
If Postgres is having any issues starting up, details should be in the log
file. I don't know where that file gets written on a Windows system though,
perhaps it ends up in the Windows Event log?
What procedure did you follow to move your data to the D-drive? That seems a
likely cause of trouble, especially if the database was running while you
did that - you may be looking at an unrecoverable database snapshot if you
didn't take precautions, in which case the database would refuse to start
up.
Alban Hertroys
--
If you can't see the forest for the trees, cut the trees and you'll find
there is no forest.
