Issue with SRP Utilities install with Editor

Opto_Will

I notice these days that there is a lock check on SRP Utilities when installed with the Editor. That is a great improvement from when it used to just fail silently if the file was in use.

However, it would appear that the Utilities part of the install happens after the Editor RDK procedures are installed? Therefore if the Utilities is locked and I abort the install then I appear to get mismatch between the stored procedures and the running SRPUtilities.dll. (i.e. I only find out the Utilities is still locked after the installer has already done some work that cannot be rolled back).

My question is, is it possible to run the Utilities DLL component first so that if it is locked and I have to abort then there will be no mismatch with stored procedures?

Long story short I was running the new critical update patch on a client that was running 3.2.0.5 and a unbeknownst to me some users had jumped back on. The SRPUtiities.dll was now locked and wouldn't update so I aborted but then all sorts of problems surfaced. I ended up killing the users so I could do a clean update and then no more problems.....

KevinFournier

I might need some more details because the order of the installer is this:

1. Lock check SRPEditor.ocx
   
2. Lock check SRPUtilities.dll
   
3. Copy SRP Editor RDK to temp folder
   
4. Copy SRP Utilities RDK to temp folder
   
5. RDKINSTALL SRP Editor RDK
   
6. RDKINSTALL SRP Utilities RDK
   
7. Remove temp RDK folders
   

The lock check is actually a delete check. If it cannot delete the DLL, it aborts. If it can, then it continues. Can you confirm what kind of errors they were getting? Perhaps the issue is not order but the fact that the DLL was deleted and the users were running SRP Utilities without a DLL.

At minimum, I should have a method of restoring the original DLL if the lock-check fails and needs to abort.

Opto_Will

Kevin,

I think you might of hit the nail on the head! I made the likely incorrect assumption that the procedures had changed (based on the image below) and were causing a mismatch but really it might have been a missing DLL alltogether (that I failed to check at that stage as it was there a few seconds earlier before I started the install process).

I have been playing aound locally and, while I cannot replicate the delete yet, I can see what you are talking about. Like you noted, the Editor OCX gets deleted and then the process stops at the locked Utilities DLL . Mind you, I do recall yesterday after a bit of stumbling around that the DLL might have been missing but I think I put it down to trying to rename it. I just cant recall the sequence of events enough to confirm the behavior.

I can't remember the exact errors from yesterday but I am getting similar (if not the same) ones now after I forcibly remove the DLL to try and replicate the behavior you noted e.g. debugger message SRP_HASHTABLE_CREATE code not available. Pretty much confirms what you suggested.


I didn't notice the Editor OCX was already deleted as we generally copy it out and register it elsewhere but I noticed that in the tests. It might be worth restoring the original OCX as well if aborted for the reasons you noted.

I will do a few more tests to see if I can get the file to delete and still pop up the abort message..

KevinFournier

Actually, you bring up a good point. It's problematic if the OCX is deleted but the DLL is locked. In that case, a lack of OCX could blow things up significantly. I don't think that was your problem though since you keep the OCX in a different location. So, at minimum, I need to restore a deleted OCX if the DLL is locked.

Opto_Will

Glad I could be of service :)

You are right, I dont think that was my problem. That should only affect the Editor anyway and not the main application, correct? Pretty sure ours was the Utilities in some shape or form...

I still haven't been able to replcate the issue naturally during subsequent test installs but I am, of course, NOT retesting it on the client production machine that actually exhibited the problem :(