SQL Toolkit Automation error

[skpttc]

I am getting Automation error code -2147467262 "No such interface supported" from DBConnect called with a valid ODBC DSN from standalone .exe, but only on one machine that is otherwise identical (I think) to others on which no error occurs. The standalone .exe works on some of my target machines without creating a distribution kit but creating a distribution kit has caused cvirte version conflict problems with other existing applications dependent on it (I think), so I can't use that approach. Unsure of cvirte version on target machine; application developed with LabWindows/CVI 6.0, SQL Toolkit 2.0.6. The manual .pdf did not provide much help.

[Jattie]

The Runtime engines will most defenately make a diffirence. If you compiled on 6.0 and your runtime on the target system is of a lower vesrion you will get failures.

Also your ODBC DSN might rely on a thired party .dll, depending on the database you are connecting to. Make sure you have the proper drivers that is required. Some machines mightr have them and others not, depending on the products installed on them.

[bilalD]

You can check the version of the CVI RTE by browsing into the Windows system32 folder and looking at the properties for the cvirte.dll. As Jattie mentioned, make sure the RTE is the same version or a newer version of whatever RTE you used to build the exe.
Also make sure to go through the readme under the distsupp folder. This can be found where you installed the sql toolkit. It mentions some files you might need to distribute as well.

Hope this helps

Bilal Durrani
NI

[skpttc]

Thanks for your replies.

For Jattie:
There is a third party .dll ODBC driver involved, but that is also true for the other machines where I do not get the error; I will check on my target cvirte version.

For BilalD:
I will check the readme in \distsupp.

For Jattie & BilalD:
An existing vendor-supplied application on the target machine also relies on the cvirte and I have had serious problems (at least on one of my target machines) when using a distribution kit because (I think) a different version of the cvirte gets installed. Can different versions of the cvirte coexist on the same machine and if so how would I direct specific applications to use specific cvirte versions?

[skpttc]

Thanks for your reply...see comment to BilalD in this thread for more.

[bilalD]

You can only have one version of the CVI RTE on your machine. The RTE is fully backwards compatible, so Im curious about what kind of problems you might have run into. What was the existing version of the RTE and what version did you upgrade to?

Bilal

[skpttc]

On the one occasion that I tried using a distribution kit on a target machine, at least one other application (vendor-supplied and beyond my control)dependent on the CVI RTE was extremely slow when loading certain types of files it required and I abandoned that approach for other machines as I had to restore that machine to its prior software state after a mild of panic attack. The CVI RTE on that machine was v4.0.1p2 and I have v6.0. I have a hard drive image of the troublesome machine so I might try just upgrading the CVI RTE rather than use a distribution kit knowing I can restore everything if it also fails. I am curious about the fact that of five target machines I am trying this on, four of them do not generate this error and the one
that does has the same CVI RTE version as at least one of the others.

[Jattie]

Welcome to windoze (pun intended! 🐵

Even if you think they are similar they are not, why else woul you get the failure only on some. Determining the diffirence is the issue thou.

You might try running dependancy walker that shows you all the dependant .dll that your application calls and then determine the diffirences in the .dll's being referenced. It's a microsoft product shipped with their development systems. If you can not find i let me know.

[skpttc]

Thanks Jattie...I got the dependency walker 2.1 from dependencywalker.com...looks very interesting and once I get used to it I should be able to figure this thing out...