Sweserijnen. nl

Tag: oracle

  • Making Oracle SQL Developer with external Java JDK work on App-V 5.1

    I recently completed a project to convert App-V 4.6 sequences to App-V 5.1 sequences. One of these sequences was Oracle SQL Developer. During technical testing of Oracle SQL Developer I would receive an error stating:

    Unable to create an instance of the java virtual machine located at path c:\program files\java\jdk1.7.0_55\jre\bin\client\jvm.dll

    At the same time a co-worker had the exact same error at his customer with a converted sequence of Oracle SQL Developer. After a short search on Google I found a blog post that helped me to make the Oracle SQL Developer sequence work on the client. Just remember that not all information might be relevant for your problem, because the co-workers project demanded the  Java JDK 1.7.0_55 to be installed and used by Oracle SQL Developer. The steps to get to a solution might therefor be somewhat different.

    Steps to fix Oracle SQL Developer on App-V 5.1:

    1. Start the sequencer with the parameter -EnablePVADControl
    2. Set the PVAD to C:\sqldeveloper (if you are going to copy the Oracle SQL Developer to that location, otherwise pick the proper location)
    3. Install the Java JDK to a subfolder of C:\sqldeveloper (or the correct location)
    4. Copy the source files for the Oracle SQL Developer to C:\sqldeveloper (or the correct location)
    5. Start the application
    6. Insert Java JDK path (I installed it to C:\sqldeveloper\Java\jdk1.7.0_55)
    7. Depending on your way of sequencing (cleaning %AppData% from the sequence or not) you either have to edit the file %AppData%\sqldeveloper\1.0.0.0.0\product.conf during monitoring or in your user environment tool. Change the line AddVMOption -Xmx800m to AddVMOption -Xmx256m. Be sure to edit the correct line because there is also a AddVMOption –Xms128m line present.
    8. Stop monitoring
    9. Optionally clean the sequence of unwanted files and registry entries
    10. Save the sequence
    11. Test the sequence on the client

    A message about an available update might pop up. I must admit that I haven’t put effort yet in finding out how to disable updates in Oracle SQL Developer.

    A big thanks goes out to Hosam Kamel for his blog post (http://weblogs.asp.net/hosamkamel/resolving-unable-to-create-an-instance-of-the-java-virtual-machine-error) and the reactions on that blog that pointed me to the proper solution.

    I will also let Timothy Mangan know there is one more application to be added to the list of application needing a proper PVAD instead of a dummy. You can find the list of applications needing a PVAD here.

     

     

  • Impromptu 7.4 User Version won’t start from within Beaufort 3.3

    INTRO

    The company I work for as an external consultant consists of four individual companies merged into a new company and thus a new environment (new forest, new domain, etc etc). Every individual company carries out it’s own application migration. Two of the individual companies each use the Beaufort application and wanted to consolidate the Beaufort application (Human Resource application). As a first action their two separate Beaufort databases were merged into one of the existing databases and the merged database was placed in the new environment. It is important to know that one of the individual companies is already migrated to the new environment and the second individual company is in the process of migrating.

    In the new environment different drive letters are assigned for locations that hold either consolidated applications or non-consolidated applications and drive letters are divided to hold either the application or the application data. In the existing sequence the Beaufort application (RAET\BEAUFORT 33 and Cognos folders) was installed to K:\Beaufort and the application data (CUO, Impromptu and INTRACOM folders) was installed to M:\Beaufort. These are the locations for non-consolidated applications of the already migrated individual company. The Beaufort application worked as intended.

    Seeing that the Beaufort application needed to be consolidated I made the decision to make a new sequence instead of upgrading the existing sequence because the installation locations needed to change. I made a new sequence based on the installation manual for the existing sequence and changed the installation folders to R:\Beaufort and S:\Beaufort.  These are the locations for consolidated applications. Without this new sequence the already migrated individual company had no valid way of  reaching the merged database in the new environment.

    During functional testing we came across the problem that Impromptu couldn’t be started from within the Beaufort application. The Beaufort application has a menu structure with the option to start Impromptu. The Load catalog screen was shown but after that an error was generated on screen stating that the S:\Applicatie_data\Beaufort\EZ3.3\Impromptu\Catalogus\SE_orad.CAT catalog could not be opened. SE_orad.CAT is the default security catalog installed during the initial installation.

    TROUBLESHOOTING

    I started an command prompt within the virtual application with the command-line:

    SFTTRAY.EXE /EXE cmd.exe “<Full Application package Name>”

    Full Application Package Name is the combination of SOFTPKG NAME and SOFTPKG VERSION. After browsing to the right folder I started ImpUser.exe and Impromptu started without a problem.

    After that I started the Cognos_Impromptu.osd which I kept in the sequence and Impromptu started without a problem.

    By then I began focusing on the Beaufort database to see if it contained misconfigurations. I was looking for paths pointing to network locations of the second individual company. I started investigating Cer5.ini and IMPROMPTU.ini for misconfigurations.

    All to no avail.

    SOLUTION

    Just that day the DBA responsible for the database migration sat at the desk across from me. We started to troubleshoot together and found the problem and how to fix it. I must say that without the DBA I probably would never have found the cause of the problem.

    He started asking me about the contents on the TNSNAMES.ORA so I showed him. Entry for the merged Beaufort database was as follows:

    BO2PP.WORLD =
    (DESCRIPTION =
    (ADDRESS_LIST =
    (ADDRESS = (PROTOCOL = TCP)
    (HOST = <ORACLE-SERVER_1>)(PORT = 1522))
    (ADDRESS = (PROTOCOL = TCP)
    (HOST = <ORACLE-SERVER_2>)(PORT = 1522))
    )
    (CONNECT_DATA =
    (SERVICE_NAME = bo2pHA)
    )
    )

    This is the way how a High Available solution (Data Guard) would normally look for an Oracle database. Instead of one server name and port number 1521 a second server name is added en the port numbers are changed to 1522. I’m intentionally forgetting all the backend configuration needed for this configuration in this blog because it is out of the scope of this article.

    The DBA then informed me that the entry needed to be changed because the application Beaufort can handle a different port number but the application Impromptu can’t handle a different port number. Apparently he ran into the same problem a few weeks earlier at the second individual company.

    We changed the entry as follows:

    bo2pp.world =
    (DESCRIPTION =
    (ADDRESS_LIST =
    (ADDRESS = (PROTOCOL = TCP)
    (HOST = <ORACLE-SERVER_1>)(PORT = 1521))
    )
    (CONNECT_DATA =
    (SERVICE_NAME = bo2pp)
    )
    )

    After that we tested Impromptu from within the Beaufort application and Impromptu started and worked as intended.  Rest assured that this solution is now documented within the company (and this blog) and a warning is issued to all application owners to check all other applications if they can operate when a Data Guard solution is active.