On Feb 18, 2008 3:11 PM, Hermann Muster <Hermann.Muster@gmx.de> wrote:
> I finally found the problem. I unfortunately used an "very" old version
> of Dependency Walker which couldn't handle the libpq.dll and always
> showed that the msvcr80.dll is missing. After installing PostgreSQL 8.3
> and updating the Dependency Walker, everything seems to be fine and my
> application can use the libpq.dll. Will test it again in the next days.
Good :-)
> However, one question remains. On my clean Virtual PC Image, there is
> already a folder
> "C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.163_x-ww_681e29fb"
> containing the msvcr80.dll. After installing PostgreSQL or the runtimes,
> there is another folder
> "C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700".
> But only the path of the dll installed with the runtimes is recognized.
> Does that mean our customers have to install the runtimes at all costs?
> That would be the case if our application is running on a client, not
> the server PostgreSQL is installed on?
Microsoft have changed things so that you now have multiple versions
of the runtimes installed side by side without them conflicting with
one another - we use the latest (SP1) version (8.0.50727.762) with
PostgreSQL - something else has presumably added the earlier verison
you also have (8.0.50727.163). Any machine using libpq (client or
server) or any part of the server will need the correct version of the
runtimes to be installed.
You can avoid this by building your own libpq.dll using mingw/msys if
you like - that will work just fine with a VC++ built server.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Oracle-compatible database company