why does LabVIEW8 popup error message after i use Visual Source Safe as its sourc control?

[fredb]

Thanks for the quick reply. I probably was not clear enough. I tried the recommendations in this thread. I removed all 3 SCC entries in LabVIEW.ini. I also renamed LabView.ini. I did clear out entries while LabVIEW was not running to ensure that they were deleted. The entries did get added after I configured SCC. They were still there when I re-started LabView. I was able to easily confirm that I was in fact loading the correct LabVIEW.ini file. However.... each time I start up LabVIEW, my SCC provider is set to <none> with all the fields greyed out - and, sadly, there are no error messages.

Once I re-establish the connection to VSS, I am back to full functionality.

However....

If I choose to not re-establish VSS before I open up my project, I do get an error message as follows:

Error -2976 occurred at

SCC_Item_Init.VI.ProxyCaller

An error occurred trying to access the status of the specified file(s)

Possible reason(s):

LabVIEW:  Invalid source control reference.

FYI, I have uninstalled all NI products, cleaned out the registry with msBlast and then with msicuu, then re-installed LV.

The problem still exists. By the way - there were no dangling entries in the registry - so no cleanup occurred.

Fun stuff, huh?

Thanks again,

fredb.

[gmart]

1. Once you configure, if you go back to Tools>>Options>>Source Control, are your setting still present? Can you create multiple LabVIEW projects and work with your files with no problems (errors, etc)?

2. The error you described that comes up when you see the problem (provider set to None and you don't reconfigure) makes me wonder if the configuration data has problems. Would you post what the ini entries are after you configure successfully (if that is possible)?

Thanks for your patience. Debugging these kind of problems are tricky, but hopefully we'll narrow this down.

[fredb]

Yup - once I get to the startup screen, re-establish SCC Provider, I can open projects, close projects, open other projects ad nauseum. The only issue that I see is that once I exit labview, next time I start up, back to no SCC provider.

The relevant settings in the .ini are...

SCCConfigData="fredb;"$/CRS Test Exec", SLFAAAAA;C:\AAATESTEXECHOME;\\usdanrmmd1ms018\mfgvss\Mfg_Eng_Vss,"
SCCProviderName="Microsoft Visual SourceSafe"
SCCProviderLocation="WinCI"

I can send you the whole thing if you'd like.

The best way to describe the symptom is as a feature! I've somehow managed to enable the 'clear SCC provider on exit' option.

thanks,

fredb.

[gmart]

I am assuming that you need to reconfigure because you open your LabVIEW projects or VIs and the environment shows that source control is not enabled.  Is that correct? In other words, what happens if after you close down LabVIEW after reconfiguring you don't immediately go to the Options page and just open files or projects that you know are in source control? Another check is trying to use the source control palette VIs located at Connectivity>>Source Control. You could try dropping an SCC Open SCC Project - SCC Not A Source Control Reference - SCC Close SCC Project and see what the value returned by Not a Reference is. If it is false (valid reference), try using other VIs (such as Properties or History) and see if they work.

[fredb]

Ok - here we go...

Started LV, connected to VSS. Opened up a new VI, dropped in a few SCC toys as you suggested with the following results.

Was able to connect and check file status. Very cool stuff - did not know it would be so easy to do this - this solves a problem I've been deferring - so thanks for that - I know have more work to do 🙂 (I'm attempting to force strict revision controls on a library, so we can qualify it, deploy it, and during runtime (as an exe) verify that we are running a qualified library - unfortunaly vi server does not preserve this info - so I've developed a home brew scheme and have taken over the process of building the exe - but that's not getting us any closer - just me getting excited that I can now check the revision vi out, modify it, check it back in - run the build. Woo hoo!

Ok - back to reality here.

So - the SCC VI's are able to connect and play nicely with VSS after I set it up. BUT - when I went to save the VI, I got the same -2976 error. It did save the VI.

I then started LV again - did NOT connect to VSS, opened up the SCC vi I saved above, ran it, but this time, received an error - was not able to obtain the source control reference.

When I connected to SCC (via the tools menu of the VI), I got the -2976 error again, actually - I got it a whole bunch of times. Once I got past all the error dialogs, I then ran the VI, and it worked correctly, returning the status of the file I have under SCC.

FYI - when I exited the VI, got back to the Getting Started page, I checked into the SCC, and it now had the configuration. Just for chuckles, I decided to exit LV, get back in - and sure enough - back to <none>.

Thanks for your patience with this. Hopefully you'll be able to narrow it down. I'm still thinking that it may be related to an entry in the registry that is preventing the SCC from loging me in - such as a missing password. Probably just another red herring.

fredb.

[gmart]

At this point, I am tending to agree that something external to LabVIEW is causing this behavior. If there is a problem connecting to the configured provider, usually a warning dialog will come up telling you this when you start LabVIEW. If this is truly a password related issue, I don't know if VSS considers this a bad enough problem to error out so we may be allowed to continue not knowing that VSS really didn't initialize properly. So when you run the Options dialog, the code notices that the connection reference we are using is not good and resets everything. Based on what you said with the SCC VIs, this seems to be the case. What I am surprised is that you are not seeing a message in the options page such as that in the attached picture.

At this point, I would check with you VSS admin and see if something is up on that side of things.

[fredb]

I hate doing this stuff via e-mail!

Glad you attached the picture. In fact, that is exactly what I am getting! I thought you were asking earlier if I was getting any over error messages and therefore assumed that the note at the bottom was of no interest.

By the way - I am the VSS administrator. Oh joy!

Sorry about that,

fredb.

[fredb]

One of these days I'll learn to type too. I meant to say 'overt' error messages.

[gmart]

Phew! Ok, it looks like indeed you are in the state where for some reason the configuration data you entered is not valid in a new session. When you exit LabVIEW, we close the "working" connection. The next time LabVIEW runs, it uses the configured data. If there was a problem with the data, you will be this behavior. At this point, I think the problem is moving towards VSS either not prompting you for a password or some other odd configuration problem. Sorry for the drawn out session. It's too bad you can't blame this one on your VSS admin Good luck.

[fredb]

Phew? No - wait!

VSS never did prompt for a password when it is linked to labview. It must be tucking it away somewhere. I would simply start up labview, and it would re-establish the connection. I could go ahead and uninstall LV, totally wipe out the registry items, re-install, but do not want to do this unless I know for sure that LV is tucking SCC stuff in the registry. I doubt it has anything to do w/ my source control - I was able to replicate the problem by crashing out of LV. VSS was running in the background while all this took place. It was happy before the crash, happy after the crash, in fact - still happy.

Any thoughts?