From: Saga on

I have two aplpications, one is a Standard EXE, the other an ActiveX EXE. These have been
running for over a year, each with succesive modifications. Today I modified the ActiveX EXE
component. Specifically, I tweaked an error handler and increased the SQL Server timeout
to 10 minutes.

I compiled the components and placed in the production folder. When I went ahead to test it
I got the error in the subject. Other times (albeit very seldom) that I get this error it is usually
due to a problem with the registration of some component; however this time I do not believe
this is the cause.

I Googled and found various occurances of this error, some due to ADO, some to do with
external programs (Excel, Crystal Reports, VB6 IDE).

I have though of creating a setup package and resintalling the app, or reinstalling the MDAC,
but I do not want to loose the functionality I have now if something should not go as expected.

Any ideas?

Here is another mystery. Now whenever I recompile the ActiveX EXE, no matter how slight the
modification (ie, does not involve the interface), I must also recompile the Standard EXE app,
otherwise, when I run it and the app attempts to instantiate the ActiveX server, it gives me an
error 13 (type mismatch). I have already stepped through the code and the error occurs after
the end of the executing procedure. I suspect these are related.

I have some junk in my references. There are three references to the ActiveX EXE, two of
which are obsolete. I can't seem tobe able to get rid of these. I also Googled this and some
one in a group (I believe it was this one) had good results with regclean. I got this utility and
ran it. The three references are still there.

I just thought I'd give all this info, it might (or might not) be important. I am using VB6, SP5
on Win XP.and ADO 2.7.




From: Saga on
Correction, the error number is -2147221163
My bad





"Saga" <antiSpam(a)somewhere.com> wrote in message news:%233N18WbDHHA.3520(a)TK2MSFTNGP04.phx.gbl...
>
> I have two aplpications, one is a Standard EXE, the other an ActiveX EXE. These have been
> running for over a year, each with succesive modifications. Today I modified the ActiveX EXE
> component. Specifically, I tweaked an error handler and increased the SQL Server timeout
> to 10 minutes.
>
> I compiled the components and placed in the production folder. When I went ahead to test it
> I got the error in the subject. Other times (albeit very seldom) that I get this error it is
> usually
> due to a problem with the registration of some component; however this time I do not believe
> this is the cause.
>
> I Googled and found various occurances of this error, some due to ADO, some to do with
> external programs (Excel, Crystal Reports, VB6 IDE).
>
> I have though of creating a setup package and resintalling the app, or reinstalling the MDAC,
> but I do not want to loose the functionality I have now if something should not go as expected.
>
> Any ideas?
>
> Here is another mystery. Now whenever I recompile the ActiveX EXE, no matter how slight the
> modification (ie, does not involve the interface), I must also recompile the Standard EXE app,
> otherwise, when I run it and the app attempts to instantiate the ActiveX server, it gives me an
> error 13 (type mismatch). I have already stepped through the code and the error occurs after
> the end of the executing procedure. I suspect these are related.
>
> I have some junk in my references. There are three references to the ActiveX EXE, two of
> which are obsolete. I can't seem tobe able to get rid of these. I also Googled this and some
> one in a group (I believe it was this one) had good results with regclean. I got this utility and
> ran it. The three references are still there.
>
> I just thought I'd give all this info, it might (or might not) be important. I am using VB6, SP5
> on Win XP.and ADO 2.7.
>
>
>
>


From: Bob O`Bob on
Saga wrote:
> Correction, the error number is -2147221163


Probably not important.

Does it persist after a reboot?



> I have some junk in my references. There are three references to the ActiveX EXE, two of
> which are obsolete. I can't seem tobe able to get rid of these. I also Googled this and some
> one in a group (I believe it was this one) had good results with regclean. I got this utility and
> ran it. The three references are still there.

Are you familiar/comfortable enough with RegEdit to give that a try?
You should be able to search for your AX EXE name and "trim the trees" in which it appears.
Then you probably should do a little research on VB project compatibility settings before
recompiling. Here's one reference <http://vbsight.com/BinaryComp.htm> but you might
want to search up several.



Bob
--
From: J French on
On Tue, 21 Nov 2006 15:09:39 -0800, Bob O`Bob
<filterbob(a)yahoogroups.com> wrote:

<snip>

>Are you familiar/comfortable enough with RegEdit to give that a try?
>You should be able to search for your AX EXE name and "trim the trees" in which it appears.
>Then you probably should do a little research on VB project compatibility settings before
>recompiling. Here's one reference <http://vbsight.com/BinaryComp.htm> but you might
>want to search up several.

I've found that using Late Binding with AX EXEs tends to work
- just running the blighters tends to register them ( although it
should be /R[egister] )

Another approach is to simply get rid of all the AX stuff and use
WM_COPYDATA to punt the bytes to and fro.

One day MS will wake up and realize that the registry is actually a
very bad idea.


From: Saga on
Thanks both.

Not a problem with Registry, can look for AX name and trim, I just was not
sure if it was as simple as that.

Persisting after reboot? One thing for sure, it is I who won't persist if I reboot
this server since it is in continuous use, perhaps this can be done over the
Thankgiving day holiday :-)

I will check out the URL regarding binary compatibility. I have done research
on this topic, but I still can't get a grip on it. I started out using Project Com-
patibility, then switched to binary compatibility once forst EXE was generated
and have selected a new compatible EXE whenever the interface was modified.

Agreed about registry being a bad idea, I suspect that my problems originate
there, unfortunately, I am unable to locate problem.


Thanks again
Saga

"J French" <erewhon(a)nowhere.uk> wrote in message news:45644f4f.8600638(a)news.btclick.com...
> On Tue, 21 Nov 2006 15:09:39 -0800, Bob O`Bob
> <filterbob(a)yahoogroups.com> wrote:
>
> <snip>
>
>>Are you familiar/comfortable enough with RegEdit to give that a try?
>>You should be able to search for your AX EXE name and "trim the trees" in which it appears.
>>Then you probably should do a little research on VB project compatibility settings before
>>recompiling. Here's one reference <http://vbsight.com/BinaryComp.htm> but you might
>>want to search up several.
>
> I've found that using Late Binding with AX EXEs tends to work
> - just running the blighters tends to register them ( although it
> should be /R[egister] )
>
> Another approach is to simply get rid of all the AX stuff and use
> WM_COPYDATA to punt the bytes to and fro.
>
> One day MS will wake up and realize that the registry is actually a
> very bad idea.
>
>