From: Saga on 21 Nov 2006 16:40 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 21 Nov 2006 17:14 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 21 Nov 2006 18:09 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 22 Nov 2006 08:29 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 22 Nov 2006 10:56 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. > >
|
Pages: 1 Prev: RetrieveUrlCacheEntryFile example Next: How to read from USB port? |