As with most error messages this one is not very helpful, simply indicating that a module count not be found. Fortunately this was working on my local workstation, however the issue was present for test users on their thin client environment, so it was just a matter of finding out what was different between the two environments. After some investigating I remembered that I had manually added the TRIM client installation directory to the PATH system variable to enable running a web site which uses the HP TRIM SDK. Removing the installation dir from the PATH variable did indeed result in the same error message, and funny enough adding the dir back resolved the issue, on both my local instance and on the thin client instance. I don’t know why the TRIM client install doesn’t just add the TRIM directory to the PATH variable by default. Oversight by HP? I’m sure it used to be… there are also plenty of SDK related forum posts suggesting to add it when starting your application (that doesn’t really help in this instance).
To add the TRIM installation directory to your PATH system variable go to your system settings; (start» type “Edit the system environment variables”) or (start » right-click Computer » Properties » Advanced system settings) » Environment Variables » under System variables locate and selectPath » click Edit » append your TRIM install folder (default TRIM installation directory should be either ;C:Program FilesHewlett PackardHP TRIM or ;C:Program Files (x86)Hewlett PackardHP TRIM depending on your installation preference.
If you’re using the Microsoft Word integration feature with HP TRIM and receive the error message “Could not load file or assembly ‘HP.HPTRIM.SDK’ or one of its dependencies. The system cannot find the file specified.” chances are you probably have a generic .NET Add-In registered in your TRIM dataset for the record type you’re trying to save your word document as.
To solve the issue you can copy the HP.HPTRIM.SDK.dll from your Trim installation folder into your Microsoft Office executable folder (e.g. C:Program Files (x86)Microsoft OfficeOffice14 or C:Program Files (x86)Microsoft OfficeOffice14 *note your office version may vary e.g. Office11, Office15, etc).
There may be another way to resolve this issue, but so far it’s the easiest and only fix I have worked out.
Recently I was getting the error 0x80030002 STG_E_FILENOTFOUND while trying to run any TRIM 7.3 Outlook Add-In function. The Outlook Add-In had loaded fine and was bringing up all the available TRIM options, it was just when I tried to execute one of the options that it would throw the, oh so very “helpful”, error message as with most COM operations. It wasn’t until I found this thread over in the HP forums that I discovered that Cisco Unified Personal Communicator can interfere with the TRIM Add-In. According to another post any ODMA integration can cause issues with HP TRIM’s Outlook Add-In, in their case it was Novell GroupWise causing the issue.
Fortunately for me, Cisco Unified Personal Communicator was no longer required to be installed (and has been replaced by Jabbr – although I did not test if Jabbr causes issues with TRIM’s Add-In), so to resolve the issue I just had to uninstall Cisco Unified Personal Communicator; for good measure I also did a repair of HP TRIM Microsoft runtimes for VS 2008 and a repair of HP TRIM.
Having changed to a 64-bit development machine at work recently I ran into an Oracle error while trying to generate files using CodeSmith. This error was ORA-06413: Connection Not Open. Assuming it was a connection string error, as I had not ran this particular generation in some time and it was likely that the server or username/password had changed, I proceeded to test the connection from SQL Developer. Success!
After ruling out that the connection was indeed valid I did a quick Google search for the error message. After a few clicks I discovered a very well known (has been around for a few years) Oracle issue; When executing an Oracle command from an application with parentheses or equals — ‘(‘ or ’)’ or ‘=’ — in the path then the specified error message is thrown.
In this particular case CodeSmith had been installed under C:Program Files (x86)CodeSmith which was causing Oracle to fail. The quickest workaround was to simply move CodeSmith from the Program Files (x86) path e.g. into C:CodeSmith. However; there is a patch (5383042) for Oracle 10g, which I believe is also applied to Oracle 11G.