LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error -2147352571 type missmatch using microsoft excel 97

I am getting error "Error -2147352571 Type mismatch' when running my built application on a non-labview development computer (aka only runtime installed plus others but not the development environment).  This computer is an Windows 2k machine with Excel 97 on it.
 
I developed the program on a Windows XP machine.  This computer has Excel 97, Microsoft Object Library excel 8.0 and 5.0 on it, as does the 2k machine (I believe that i used the 8.0 library for the activeX controls).  I can run my built application on the windows xp machine just fine.  but when i run it on the 2k machine, i get the error.
 
i have checked that both librarys are present on both machines, as well as the *.tlb files.
 
I do not have any subvis in the activex control (this was initially why i was getting the type mismatch error even on the my developement machine).
 
I included the -word dynamic and _excel dynamic llbs as dynamic and support files.
 
Excel is loaded from a novell server at the site, so it is the same on any computer.
 
Any ideas??
 
Kenny
Kenny

0 Kudos
Message 1 of 7
(3,993 Views)
Kenny,

do you per chance know which function creates the error?
and can you test that issue with a third PC with either XP/2000 where LV developement environment is installed?
another point you check is if there is some sort of problems concering firewalls/DCOM-settings. since you are loading excel from a netwerk-server, you have to make sure that all settings are compareable.

Norbert B.
Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 2 of 7
(3,985 Views)

Sorry it took so long to get back to you.

I tested it on the computer that is having problems, and I installed the developemnt environment on it so I could see the errors.  The type mismatch was caused because I did not have any data in the excel sheet.  As soon as I put a name in the sheet, it worked fine, so I thought.

If I run the read config by itself, it works just fine, closing excel and the process.  But as soon as I run it in my main vi, it does not close the reference and keeps the process open, so I cannot run my save vi (saves the user info and the data), although I can write my config data back to Excel.  In both the config data and the save data I am using the Excel easy vis.

If I try to save my data, Excel opens, but freezes and the table is blank (which I read and can see that the process is still in memory).  But it is wierd that I can still save to my config file.

Kenny

Kenny

Download All
0 Kudos
Message 3 of 7
(3,972 Views)

Another thing I noticed.  When I abort the vi, excel.exe disappears from the task list, as well as if i just close labview.

Not sure if this matters.

Kenny

0 Kudos
Message 4 of 7
(3,968 Views)
I did some more testing with different architectures (I am using Producer/consumer in the program) and found that i get the same results (excel stays in memory when used as a subvi).  I tried using just a while loop (shown in pic) as well as a state machine.   I also tried to use a vi server call.

Is this an issue with the while loop???  Each of the examples above uses a while loop.

Kenny
Kenny

0 Kudos
Message 5 of 7
(3,962 Views)
Kenny,

the problem with the still active excel process is that the following:
if you open a handle to the ActiveX server, a server-object is created. when closing the handle properly, the object is removed as well. but sometimes, the handle is NOT cleaned up in the proper way. and in this cases, the object still remains (as process) resulting in the errors you are observing.
the only thing you can do about that is that you make sure, that no action within your program can lead to an undestroyed object. this might include:
- special error-handling with cleanup
- removing "abort execution" from the VIs iconbar
- take care that the handle to the object is not lost

Norbert B.
Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 6 of 7
(3,953 Views)
I was able to solve the issue by replacing the close reference after the Application_Quit invoke node to a automation close.  Still not sure why it would work as a vi and not as a subvi that way, but it makes sense that you have to close the automation when you open it at the beginning....doh..

Kenny
Kenny

0 Kudos
Message 7 of 7
(3,947 Views)