10-20-2014 07:46 PM
Wow, that message takes me back. In SAS EG 4.2 the Table Analysis control was a COM control, and required a special registration step. The EG installation would take care of this, but occasionally something goes wrong and the registration gets...disconnected.
To fix, try of this step:
10-21-2014 03:13 AM
One of the consequences of building Enterprise Guide in a crappy software environment (Windows & .NET). Making such a valuable tool dependent on the "quality" of Microsoft designs was a big mistake, IMHO.
10-22-2014 08:00 AM
Kurt, I appreciate the opinions about the merits of different software development platforms -- that's perhaps a topic for another thread in another forum. However, to provide some history on this particular issue...
SAS Enterprise Guide was first developed in the late 1990s as an MFC/COM (C++) app for Microsoft Windows desktops -- the state of the art approach at the time. In the mid-2000s the team began to migrate the app to .NET, with EG 3.0 emerging as sort of a hybrid, EG 4.1 catching most of the app into .NET, and by EG 4.2 (in 2009) there were just a few legacy components still in the C++ realm. This Table Analysis control was one of them, as it included non-standard UI with lots of "owner draw" code. The connection points between COM and .NET components can be fickle, and they are especially sensitive to installation problems.
In EG 4.3 and later, virtually all of the application components are now based in .NET, and installation-related troubles within SAS Enterprise Guide are relatively rare.
10-22-2014 08:44 AM
Chris, you are claiming that installation-related troubles are rare with SAS Eguide, well.....
There are a lot of old versions not being upgraded around there in the world. There must be a reason for that, what is that reason do you think?
Bigger companies are using a closed desktop approach where only allowed applications may be distributed in some predefined way. That msi approach with 9.4 is an improvement to get that into those processes.
The by SAS mandatory use of a software-depot sdw and sashfadd is adding more complications as it is solving. The .Net dependicy is delicate one on his own as there are often .Net policies in place. When they are getting conflicting with SAS that is an issue. That one has lead me to Caspol.exe (Code Access Security Policy Tool) as there are differences in local-intranet (network attached drives) and real local drives. I found also the Xceed libraries Xceed Home being used by Eguide. All of this by investigations on why it did not fit into some common approaches and getting weird errors.
It is not that EGuide is build using wrong tools, it is more there is not sufficient vision to align that with common processes in place or needed to be implemented at all customers.
Indeed "Wow, that message takes me back" the sas releases at the customers should not get that old.
10-22-2014 09:05 AM
Oh yeah. Installed EG 4.3 = 159 MB (Including Misc and Shared Files!), SAS depot necessary for this > 1.5 GB. VERY useful for silent installs over the network. And the silent install in Windows 7 regularly completes without installing the itclient or the language packs. May be the microcrap, but who knows?
I am already looking for a nice place to spend my psychological rehab after upgrading to SAS 9.4 and EG 6.
10-22-2014 09:23 AM
Kurt, relax SAS is sometimes hearing their customers. SAS(R) 9.4 Intelligence Platform: Installation and Configuration Guide There are msi approaches for AMO and Eguide. So you can go for more normal processes.
Missing is the Base/Foundation that way (not mentioned). Java clients can be solved in an other way. Going for app-v way (that one is now hyping) there are several papers http://support.sas.com/resources/papers/proceedings13/461-2013.pdf and http://support.sas.com/resources/papers/proceedings14/SAS105-2014.pdf .
The biggest challenge will be cooperation with SAS to get speed up those release migrations while maintaining all in house requirements and policies of your company (not necessary the same as SAS ideas) .
It is quite different than thinking on working as "my laptop" that is a culture shock.
10-23-2014 03:00 AM
The best SAS development path at the moment is SAS Studio, IMO. That breaks the Windows lockin on the client side. It is the reason why I want to speed up our migration to 9.4 (but need a new server with AIX 7 first), because we could find that most users won't need a fat client anymore, so we can install the few ones needed manually.
Just looked up app-v. Oh.My.God. SAS should not even touch that with a ten foot pole while wearing protection suits. Nobody in their right minds can expect that to work at least somehow before release 7, given MS's track record. And it will always be an abomination and cause the developers grief by ever-changing APIs etc.
10-23-2014 04:15 AM
Kurt, relax it is not SAS promoting that V-APP, it is becoming the standard with Windows desktops as a delivered service (DAAS). That is often by third party providers in bigger companies. The service desk is often also outsourced. I am assuming you are having a similar situation as all of that bigger organizations are doing it the same way. Root cause: old boys networking.
The reason is all those application stacks (SAS Oracle Excel SAP classified as applications) making a mess and getting into conflicting requirements (ddl hell). Hoping app-v will be the solution for a stable OS an the desktop.
As this is an external requirement for SAS and the others there is little choice, either join them or fight against it. Going for a new desktop strategy aside the official one is a fight (yes it happens).
For the java clients it could be that lot easier as they are running already in a virtual machine with a zero impact on Windows. Just isolate that JVM (JPRE).
The most easy approach would go for zero impact deploy (no app-v or whatever needed). To recognize those kind of approaches some vision is needed.
The webstart approach is looking nice but introducing a dependicy to java in the browser. With that a dedicated sas browser is going into a app-v, could think the same on flash.
For evaluating SAS studio I would advice trying to use UE. It works but is having also a lot of weak points. May be it is sufficient or it is the next frustration.
Those msi packages you must like them It think.