CRoebuck

Using the ActiveX API can yield some odd behaviour if you then "manually" interact with Excel, launching another instance for example. If you have long running tests then I suggest that streaming to Excel is not ideal. Might be better to write to a database or TDMS file and then arrange for the data to be exported in an appropriate manner. Remember there are size limitations to the number of rows you can have depending on your Excel version, again worth consideration. All that being said, if I can help with the Excel API then just ask Chris

Jeremy, It was great to see you again and a pleasure to meet your wife. She's probably pre-registered for next year already. She looked like she was having an awesome time. We'd love to have you over for the European CLA summit next year !! You guys should visit Europe. Failing that, see you at NI Week 2015 :-) Chris

Thank you Mark. As always the LabVIEW community who could not attend any (or all) of the sessions are in debt to you for your efforts. Many thanks. PS. Great to see you !

I believe that LabVIEW checks for the presence of a configured license server before querying for locally installed licenses, perhaps this is the cause of the registry queries ?

Hi Vivu, I've had similar issues in the past and whilst I do not have a concrete solution for you I do have some suggestions that have worked for me. is it manadatory to keep the dl's and their dependencies in the same folder, in which VI's use them, for sucessful build through deployment ? if yes, by default, these would go to "installation directorydata", which is different from "installation directory...VI directory , and would not work still? >>I would say that the dll's should be placed in a location that will be a duplicate of their location when deployed. So in development you might call them form C:UsersApp Dataxxxxxx and then deploy to that location also, this will maintain the linkage and prevent the VIs from being broken, the test stand deployment utility is placing the assemblies in a different location because there's no guarantee that vi/.lib will exist on the target machine (if just using labVIEW RTE for example) it is mandatory to add the VI's that use .net assemblies to labview project, for sucessful deployment? if yes, how do we add a labview project to testsand workspace? In each step call when the step is being performed by a VI there is the option to specify not only a VI path but also the project in which the VI resides. Chris

Eeesh Neil, Did you ever get to the bottom of this or just re-create and move on. I've got the same issue here this morning (least I think it's the same). Constant bundled in updates the cluster, wiring in a "variable" does not. Probed the wire, input data is valid. Re built the VI and moved on. I had seen crashes too when making changes to the class so perhaps like you we've managed to upset LabVIEW. I'm moving on the next issue but this is leaving me with a prickly sensation on the back of my neck, all is not well somewhere.

If you change the data type of this field in the database to nvarchar(max) do you still get the same issue ? If you set a field to be varchar(x) then the string stored there will be x in length even if the string originally stored was shorter. When you query the database you will get back a string of length x. Using nvarchar will store a variable length string up to length x.

Hi, I have done several things over the past 10 years at various organisations where I have worked. 1. I've created my own SQL based storage framework (codeless storage using a custom process model) 2. I've purchased commercial test data management and analysis tools 3. I've used the default storage schema s All have their own relative merits and drawbacks. PM me if you want any specific information about the tools I've used. Chris

PSY may have just been de-throned !!!