Carl,

>Again, I don't like this but I can see where you are coming from.

I know.....nor do I. But a quick and dirty !

> don't follow the format/reinstall. Did you find any other dll's (or other
>files) that might be causing this problem?

Since I couldn't get either PC Anywhere or SQL Server to run. Both are
critical to my work...I had to find a quick solution...I tried writing my
own tool that uses the install API to switch the dll, but that failed, I
wrote an installation program using Installsheild but that failed too. I
downloaded a fix for this dll from the M$ site, but that failed. I tried
re-installing MS SQL Server and that failed too.
So...reformat...reinstall...was the easiest sure fire option.

By the way...the above all failed with the message that the current DLL was
read only and so could not switch the DLL which the system tries to do when
it boots up.

>SVCRT was probably in use (by what I don't know). Was InterBase running?
>id you try putting the MSVCRT's that these apps "liked" in their own
>directories?

The whole idea of using the Install API is that if the DLL is in use it will
swap the dll when it boots up next. Before any of the services kick in...but
it could do that.

What I failed to mention during all of this is, that the M$ patch needed a
component of Visual Studio to be present on the system. So I installed VS.
Still no luck. Then installed the patch...lo and behold, the dll was finally
swapped ! So I know it's the dll. After that I did all my other stuff on the
other machines. I have one machine on which that patch (with VS) was
installed and all applications work fine including PC Anywhere and SQL
server. But it's also got VS installed on it which I don't need or want....

Shiv.

-----Original Message-----
From: Carl J. Mosca [mailto:cmosca@...]
Sent: Monday, June 12, 2000 6:11 PM
To: IBDI@egroups.com
Subject: Re: [IBDI] Installation Problem on W2K - solution...

Shiv,

> I too have multiple versions of that dll. I think what really happens is

the

> Microsoft does not stick to its specifications and so vendors would rather
> have the dll local to their applications so they don't depend on the

system

> dll (in C:\winnt\system32). Rightly so !

Yikes. I am familiar with how dll's are found, etc. but it really rubs me
the wrong way to have multiple copies of the "same" dll. I cannot think of
a good technical reason why the latest version of the dll shouldn't work in
all cases. I do realize however here in the real world this is not reality.
It does, on the other hand, fly in the face of one of the main points of
using dll's.

> This is what I am suggesting for the Interbase install. Install it in the
> local folder. That way, we can have other applications running...

Again, I don't like this but I can see where you are coming from.

>
> On one of my servers, I had PC Anywhere and SQL server installed and

working

> fine before I attempted to install Interbase. Both stopped working since.

So

> I had to format and reinstall the OS and other software without Interbase.

I don't follow the format/reinstall. Did you find any other dll's (or other
files) that might be causing this problem?

>
> But it didn't work like that. Neither PC Anywhere nor MS SQL server could
> get rid of that dll. They both complained about the fact that the dll was
> read-only and that I will have to reboot etc. So I did, but they bombed

out

> on re-boot saying they couldn't find the entry point.

MSVCRT was probably in use (by what I don't know). Was InterBase running?
Did you try putting the MSVCRT's that these apps "liked" in their own
directories?

(Sorry if I am asking questions about roads you have already traveled...I'll
do some looking, too.)

Carl


------------------------------------------------------------------------
IT Professionals: Match your unique skills with the best IT projects at
http://click.egroups.com/1/3381/4/_/679568/_/960847367/
------------------------------------------------------------------------

Community email addresses:
Post message: IBDI@onelist.com
Subscribe: IBDI-subscribe@onelist.com
Unsubscribe: IBDI-unsubscribe@onelist.com
List owner: IBDI-owner@onelist.com

Shortcut URL to this page:
http://www.onelist.com/community/IBDI