I started this blog when I started using Windows 7 initial release and was struck with end number of issues, mostly related networking.
I am turning my attention towards Windows OS, minimum for a while as I am dealing with another Windows OS, that is crap like no other times…Windows Server 2016, which, looks and feels like Windows 10 with server OS capacities (to certain extends). A totally screwed up Server OS which has half of the settings over modern layout and rest on the legacy
This time I am going to discuss about a peculiar situation that arises once after removing “Remote Desktop Services“ from Windows Server 2016 & trying to initiate a normal RDP session with the server.
It just won’t connect. That’s all. You check for the usual stuffs everywhere and realize that everything is set fine, firewall, permissions. Yet, you won’t able to connect.
After trying to fix “few” things myself, I gave up and started searching for some answers. One of the most interesting things I learned about Windows Server 2016 is, there are hardly any forums discussing anything at all about this particular OS. 99% of the results I am provided were either for Windows Server 2008 or 2012 & for few situations not a single result for 2016!
& by the bottom of the page found a link to Dell site where a solution was provided for Windows Server 2012 R2 to recreate the RDP-TCP registry values. As I was dealing with a VM, which is already backup, I decided to give it a try
I’m copying the instructions here, for the reasons that the above link may not be available after a while.
1. Recreate the default RDP Listener
How to recreate the RDP listener.
1. Export the following registry key:
2. Delete the following registry key:
3. Copy and paste the below text into notepad, and save the file as RDP-Tcp.reg. Additionally, if the operating system is 2012 R2, another file will be required with the contents of the second box.
Recently for a new hardware, we opted Windows Server 2016, which was suggested by the vendor and our logical thinking that we are already by the mid of 2018 and we should have a recent server OS.
Although we bought the OS, we didn’t use it until our recent Citrix deployment for a legacy application that is 20 years old, based on Oracle forms and reports (Developer 2000 6i)
Everything went as expected, but the printing. 1st of all we were expecting some misconfigurations from Citrix & came to conclusion that we will address the direct printing requirements from the legacy mini ERP by changing few stuffs here and there.
In order to make sure that no mistakes were been made during Citrix implementation causing such a hiccup, I decided to setup a lab environment (Actually the legacy application sources I have and the latest compiled are bearing different time stamps, hence I was skeptical about recompiling those forms after changing the printing routines…)
So I picked up a Windows 2012 R2 physical server, setup Citrix following the documents provided by our implementation partner, which had minutely detailed explanations with screenshots how to install and configure Citrix XenApp 7.15.xx
After setting up the store front, I accessed the published application and the default printer was the one I have as default in my laptop! This caused me more confusion, so I decided to recreate the exact setup once again using Windows Server 2016
I built a VirtualBox VM using evaluation version of Windows Server 2016 standard edition and patched it with May 2015 cumulative update before setting up Citrix. I was able to reproduce the printing issues once again & I decided to find out what was the real cause behind two different behavior between Windows Server 2012 & 2016!
Kept on searching for any kind of information & came across couple of TechNet discussions
I dug deep into the registries of both OS after a normal RDP to confirm that Windows Server 2016 retains local printer for the key “HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows:Device” while Windows Server 2012 maps this key value with the default printer redirected from the client during a RDP session!
I couldn’t find a valid explanation or solution for Windows Server 2016, hence asked the implementer to redo the Citrix deployment using Windows Server 2012.
Now the topic cannot be justified just because we had some issues with an outdated legacy technology, should have more
Windows updates: I never experienced such kind of broken stuffs with Windows update that Windows Server 2016. It looks and breaks like Windows 10 & reminds me a BIG mobile phone than a real server OS
Windows Domain Administrator account has “Not enough privileges” to interact with desktop icons & more. This OS is almost 19 months old & Microsoft hasn’t fixed the above “bug” until date, so you could guess what kind of progress they might have had with this particular OS!
There could be more than what I have listed above with the OS that is still half baked. I am sure the printer related issue that I have narrated above MUST be another bug & future releases “may” address it.
So, unless you are true risk taker, I suggest to continue with Windows Server 2012 & only to use Windows Server 2012 in the test/development environments and to avoid straight away going with the OS for production deployments.
Downloading the installing Oracle software could be a challenging task at times, WebLogic 12c Forms & Reports installation is NOT very different Especially if you are as usual skipping the “read me” areas)
I will try to explain the download and extraction activities related Oracle forms and reports 12c below.
Once the files are downloaded, you need to extract both the zip files into a single folder
1st ZIP archive extracts “setup_fmw_184.108.40.206.0_fr_win64.exe” & 2nd ZIP archive extracts “setup_fmw_220.127.116.11.0_fr_win64-2.zip”. During installation, “setup_fmw_18.104.22.168.0_fr_win64.exe” expects “setup_fmw_22.214.171.124.0_fr_win64-2.zip”, hence, do NOT extract “setup_fmw_126.96.36.199.0_fr_win64-2.zip”. To make it simple, for Oracle installation, move the following files to a new folder, call it “Forms_Installer_12c”
and copy/move both “setup_fmw_188.8.131.52.0_fr_win64.exe” & “setup_fmw_184.108.40.206.0_fr_win64-2.zip” to this folder. Less confusing this way :)
One of the posts that is doing great according to a blogger’s expectation is about WebLogic 12c installation & configuring it for deploying Oracle forms/reports based applications.
Well, I totally missed the fact that Oracle periodically updates their software & missed out the current version of WebLogic 12c 220.127.116.11. It didn’t even ring a single bell when someone asked me about an error that was happening during his attempts to get 12c installed, which was specific to 18.104.22.168.
My previous post about WebLogic 12c strictly deals with version 22.214.171.124.0 for the areas of creating a new repository for WebLogic infrastructure and configuring a user domain. There are minor changes with 126.96.36.199, and those changes sure require mentions.
Oracle WebLogic 12c, Oracle forms and reports require Visual C++ verion 11 preinstalled. Although the installation would proceed after showing missing prerequisites, I will NOT suggest you to take unknown risks. If possible, make sure your box is completely updated with latest Microsoft patches for the specific operating system.
This time I will take the freedom to believe that you already have Oracle 12c database installed and avoid going through the database installation procedures.
As a thumb rule, install Java JDK 8, the latest version available in a folder like C:\java\jdk or C:\JDK or D:\Jdk (the shortest path name possible).
Switch to the folder where you have downloaded the software required for Weblogic 188.8.131.52 installation and configuration from an “elevated” command prompt.
Check the below image for details:
It looks like Oracle has finally realized that 99% of the public will opt skip updates, hence they made it as default this time ;)
By following the classic way of naming the installation folders, you save tremendous time & efforts to locate configuration files (Especially if you are following my posts). I always choose to install the weblogic stack on D:\Weblogic\Middleware\Oracle_Home. This helps me to setup the environment next time by keeping exact path information for configuration files etc.
That’s all folks, your Weblogic stack is installed & you are ready to go ahead with the installation of Oracle forms and reports 12c now.
Basically you shouldn’t ignore the following “Warning” about Visual C++ element. I’ve found that Visual C++ causing serious issues with OHS instance starting during my previous attempts, hence make sure you install Visual C++ recommended version is installed in the machine.
The above installation(s) should be go all smoother than previous versions & now we can move to configuring our first domain using the latest WebLogic Stack installed.
Setup repository for the domain
I suggest you totally disabling the password expiry for the entire database that you will be using for your WebLogic lab (12c). Ignoring this element could land you in difficult situations in case if you are not meticulously maintaining the password changing routines.
Always invoke scripts as administrator, this provides you the elevation on Windows 7 onward Windows OS
Execute rcu.bat from the following installation path. Please note, I have installed WebLogic software onD:\Weblogic\Middleware\Oracle_Home\oracle_common\bin folder (Which is the standard way I name the installation folder, this helps me to copy much of the elements between installations, upgrade processes), so I will be executing the “rcu.bat” file from “D:\Weblogic\Middleware\Oracle_Home\oracle_common\bin”. Adjust your path accordingly.
We will choose “System Load and Product Load” which is default for our repository as well. Please note, you should use the same “rcu.bat” for dropping the repositories, if you have to at later stages.
For all WebLogic labs, I suggest the same password for Database and WebLogic. You can go for simple passwords like “YourName123” which satisfies “most” of the implied complexity for passwords.
If you have entered the database credentials and other details correctly, the checking should be done within no time.
Now we will create the repository for our domain. Please note, the new profile name could be anything. Instead of “DEV” which is by default assigned by Oracle, you may choose your name in that place. Make sure you note down the name of the profile somewhere for future references. Select all the components as seen with the below image.
(Please note, I have copied the images from 184.108.40.206 installation and replaced few of the images with this post as one comment mentioned that I didn’t choose MetaData Services with the old image(s) provided, so please don’t get confused. Rest of the images provided may “miss” the metadata services related information & instead of “DEV”, you may see “DEV1” at places. Please ignore)
Select same password for all schema.
I have the entire setup on a SSD, hence the time to create and configure the repo could be significantly much less than over a spinning drive system.
That completes our repository creation. Please make sure that you note down the repository name and the password(s) somewhere for future references.
Now we will create our 1st domain with our fresh Weblogic 12c 220.127.116.11 environment. Just make sure that the JDK installation path is the 1st entry in the PATH environment variable.
Invoke “config.cmd” file as administrator from “D:\Weblogic\Middleware\Oracle_common\common\bin” folder. Adjust the path according to your installation preferences.
We will create a new domain for the lab now. Leave the default domain location as suggested by Oracle. Change it ONLY if you know what you are doing at this point of time.
For Oracle Forms and reports, the below product selection is spanned over 3 different images. Make a list of the items selected, and make sure you don’t miss any of them before proceeding to next step.
Once all elements are selected for the domain, you can proceed.
As a standard approach, I am using the same password for the WebLogic Administrator account, leave the suggested administrator name as “weblogic”
We’ll go for production for Domain Mode. JDK location will be automatically picked. Do not change it, unless you have a valid reason.
Now we have to supply the repository details, those we have saved during the creation of repository. The details will be cross checked prior by the configuration tool. Once after supplying the details click the “Get RCU Configuration” button.
Once the repository validations done, it’s time to select the components for your domain. Make sure the checked elements are selected for your domain as well.
Do not miss to select “WSMPM-MAN-SVR” for the Server Groups, failing will FAIL the configuration of the domain. I don’t know what the heck it is, I may read about it one day and update myself. For now, I suggest you select the said group from the drop down list and proceed.
Failing to select the Server Groups will land you on this page, which you don’t want! Make sure you will do the “WSMPM-MAN-SVR” Selection for the Server Groups.
I corrected the error at my side by dropping the repository, recreating & configuring the domain once again.
So we have created a classic domain now. We need to setup an OHS instance and setup the domain for deploying our forms based applications now.
To configure the newly configured domain, you may use the 18.104.22.168 configuration instructions as posted here
Right now, you can use my previous posts about Install Weblogic 12c and setting up OHS, forms & reports for WebLogic 12c as reference materials to setup your new classic domain or wait for me to post a followup with version specific details.
I know the subject title is not very professional this time. Yet, I want to make a claim that I figured out something, for which I spent more than couple of years time and have followed up few Oracle community threads (without much interesting results)
We had to retired a hardware that was recommended by the Oracle EBS implementation partner, within 2 years once after we went online with the R12 instance. We had 10g 10.2.0.3 with the instance, things were getting messy and slow & the new support partner recommended for a better hardware.
I always had eyes on this retired server. It had Linux, hence we couldn’t come up with a practical requirement to integrate the Linux server with our Windows domain environment and it was kept switched off until the virtualization project came online.
We needed “something” to hold a copy of the EBS instance while it was being virtualized.
So, I cloned this machine & before continuing let me describe what this is hardware is like:
[code language=”text” gutter=”false”]
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
On-line CPU(s) list: 0-7
Thread(s) per core: 1
Core(s) per socket: 4
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model name: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz
CPU MHz: 1992.000
L1d cache: 32K
L1i cache: 32K
L2 cache: 6144K
NUMA node0 CPU(s): 0-7
in addition to the local disks this server have partitions mounted from a IBM SAN.
Once the clone was done, I realized that the instance was extremely slow & our part time DBA started making excuses like “See that’s why we are changing the hardware” (He had 2G SGA and 1G PGA with 20 job_queue_processes against nearly 1TB database)
I opened few discussions with Oracle communities and was pointed towards a tone of documents suggesting me how to fine tune the hardware and database for better performances. Actually nothing were applicable as I didn’t have much hands on experiences with a database & I couldn’t find a person who could really HELP me.
Then I started taking interest about database technology, which I should have years back & came across SGA/PGA and JVM etc & as I had an idle instance, started trying out whatever I have “learned” against it.
While doing the 11g R2 the hard way I realized that I can use AMM and forget about tuning different parameters for memory optimization. Well, still the goddamn instance lagged like hell & I was almost done with it!.
Few of the persistent issues were:
After a cold boot
The login form would load at client end after waiting almost 3-4 minutes, which gets faster during consecutive attempts.
It takes ages for to open the concurrent programs window
Our custom forms & LOVs lag to extremes and so on..
Even shutting down the instance for anything was turning into a nightmare as the database always took more than 15-20 minutes and I had to kill multiple processes manually in order to bring it offline!
Then on a different note, while trying to learn SQL learning I landed against an ask Tom thread, where the asker says “I have setup both SGA and PGA 3GB”, still the SQL runs slow…
I did a fresh clone. Our database was upgraded to 11g almost year back. The default clone had 1G for both SGA and PGA. I altered them with 3G and 3G & bullseye
I went back and altered the SGA and PGA with 4G which was 40% of the total physical memory available for the hardware. I did three shutdowns and restarts of the physical server, did a dozen application and database startup to confirm that what I am experiencing is NOT a once in bluemoon phenomena. Each of my attempt to shutdown the database gracefully were completed within few seconds, not a single time I had to kill the Linux processes to bring it down!
I modified one of the main forms for a custom application and changed few VIEW calls with better logic & I can’t be happier!
Now, said that, don’t rush to me saying “I also did 4G for SGA and PGA and moron I still have a slow instance”. There are many factors affecting the performance of your database and application & most important few are:
Age of your hardware, especially the spinning disks. The aged they are, the worse the performance is going to be as there is hell loads of I/O happens when you are accessing/processing the data from a database.
Recently I was going through a MS SQL discussion about Multi-Tenant architecture and one of the contributors were discussing about a hosting firm that keeps on changing their hardware once in 6 months. I think he was just BLUFFING! ;)
I hope someone gets benefitted by the minor finding I have made YESTERDAY (6th May 2018)!
NOT FOR PRODUCTION! NOT FOR PRODUCTION!! NOT FOR PRODUCTION!!!
So, I can see that WebLogic 12c installation along with forms and reports & configuring for deployment blog posts being accessed quite often. My original posts were referring to WebLogic 12c version 22.214.171.124.0 (or 12.2.1 as documents mention), which is a buggy release from my limited usage. I’ve skipped the next version and was pretty happy with the setup until I came across an oracle blog post about version 126.96.36.199.0
As I had the complete setup fully functional, I decided to upgrade the existing, against going for a fresh installation and configuration (that should have been done!). I just wanted to see how the Oracle software upgrade works in real means…
Today I am going to share my experience of upgrading an existing WebLogic 12c forms & reports environment to the latest release.
So let us have a look at the Oracle products installed on my Windows 10 64Bit Professional edition
Oracle developer suite 6i (for supporting legacy application that is 20 years old)
Oracle developer 10g (to support our EBS R12 Business application)
Oracle database 11gR2
Oracle database 12c (for weblogic repo)
WebLogic 12c 188.8.131.52.0
Forms and reports 12c 184.108.40.206.0
In addition to the above, I do moderate level of .Net development and Android. Hence you call my development machine as a MESS in true means. Because all these software stacks are installed, I cannot setup many mandatory environment parameters for Oracle products and I always manage them manually as and when required.
Warning: The below exercises are destructive. It is your sole responsibility to make backup of your existing WebLogic installation. I suggest you using 7-Zip software for making a proper backup of the WebLogic Installation “Folder”
Start 7-zip as “Administrator”, else the archiving utility will NOT able to access all files within the “WebLogic” installation folder”
Once 7-Zip GUI interface opens, browse to your partition on which you have installed the WebLogic infrastructure
Please make sure that YOU WILL TAKE A BACKUP of your installation folder regardless the time and efforts require to make it!
Once the backup is completed, you can proceed
While using WebLogic 10.3.6, I remember upgrading the forms & reports 11g Release 1 installation with R2 just by pointing the installer to the installed folder and the installation was successful without any issues. Well, stuffs have changed. If you would try to install the Fusion Middleware 220.127.116.11.0 on top of an existing 18.104.22.168.0, you will be getting a long list of errors stating incompatibility.
[code language=”text” gutter=”false”]
INST-07545: Unexpected Error. The distribution Oracle Fusion Middleware 12c Infrastructure 22.214.171.124.0 contains incompatible features with the following:
Oracle Forms and Reports 126.96.36.199.0 [CIE WLS Shared External 188.8.131.52.0->CIE WLS Shared Config 184.108.40.206.0 (oracle.fmwconfig.wls.shared 220.127.116.11.0->[oracle.fmwconfig.wls.shared 18.104.22.168.0])]
Oracle Forms and Reports 22.214.171.124.0 [Oracle Globalization Support Files 126.96.36.199.0->Oracle Globalization Support Files 188.8.131.52.1 (oracle.nlsrtl.jrf 184.108.40.206.0->[oracle.nlsrtl.jrf 220.127.116.11.1])]
Oracle Forms and Reports 18.104.22.168.0 [Oracle JRF JAXP XML Development Kit 22.214.171.124.0->Oracle JRF JAXP XML Development Kit 126.96.36.199.0 (oracle.xdk.jrf.jaxp 188.8.131.52.0->[oracle.xdk.jrf.jaxp 184.108.40.206.0])]
Oracle Forms and Reports 220.127.116.11.0 [Oracle RDBMS files for JRF 18.104.22.168.0->Oracle RDBMS files for JRF 22.214.171.124.2 (oracle.rdbms.jrf 126.96.36.199.0->[oracle.rdbms.jrf 188.8.131.52.1])]
Oracle Forms and Reports 184.108.40.206.0 [DMS For JSE 220.127.116.11.0->DMS For JSE 18.104.22.168.0 (oracle.jse.dms 22.214.171.124.0->[oracle.jse.dms 126.96.36.199.0])]
Special Note: As usual, keep in mind, whole these exercises are done over a development environment and many of my approaches are purely non standard and doesn’t follow Oracle’s instructions. I expect you are always remembering the fair warning and not to copy the same on production environments.
Now, let us get in to the business.
Weblogic 12c 188.8.131.52 requires JDK 1.8 build 131 or later & if you have a previous version of JDK, please uninstall and install one of the recent JDK 8 releases those are available from Oracle download repos
Most of the scripts those are used with Weblogic are hard coded with the JDK path during the installation. Hence, the safest way to upgrade your existing JDK is by installing the JDK on a custom folder, for example, I always install JDK on c:\java\jdk, avoiding any release numbers attached to “jdk” portion of the folder. This guarantees that, if I upgrade to another JDK build, the path remains the same and the Weblogic scripts will NOT start screaming about missing JAVA components.
Note: While extracting the forms & reports ZIP files, make sure both the files are extracted to the same folder.
Once all the ZIP files are extracted, you should have these files in a single folder, kindly check the below image
As per Oracle’s documentation the forms installer extracts files from “setup_fmw_184.108.40.206.0_fr_win64-2.zip” when the installation is initiated. Okay, I am done with loathing Oracle for such complex installation approaches…
Install the software in the following sequence
JDK. Install and append your PATH variable accordingly. In my case, my PATH environment variable has “C:\java\jdk\bin” as the 1st entry, which is required for configuring forms and reports developers.
Select a new “Home” for the 220.127.116.11.0 installation as you cannot install the software on top of existing 18.104.22.168.0. So if you have had Weblogic 12c older version installed on
“D:\Weblogic\Middleware\Oracle_Home” let the new software installed on “D:\Weblogic12213\Middleware\Oracle_Home”
Follow the prompts and complete the installation.
Now, install forms and reports by executing “setup_fmw_22.214.171.124.0_fr_win64.exe” and point the Oracle home as “D:\Weblogic12213\Middleware\Oracle_Home” (Change the details as per your setup)
Both the stacks should be installed within 25-30 minutes time & you are all ready to do the upgrade.
Reminder 1: As usual, keep in mind, whole these exercises are done over a development environment and many of my approaches are purely non standard and doesn’t follow Oracle’s instructions. I expect you are always remembering the fair warning and not to copy the same on production environments.
Warning 2: The below exercises are destructive. It is your sole responsibility to make backup of your existing WebLogic installation. Things could get nasty during the upgrade process and YOU would lose all your deployments in case if you don’t have a backup. I would even suggest that you make a database backup of your WLS repo.
I have opened a thread with Oracle communities and Micheal Ferrante had few comments about my findings. If you are interested, please do visit the thread
So far my understanding about the whole upgrade process is like following:
Once you initiate the upgrade process for an existing 12.2.1 domain, the repository schema is updated with new information (database level)
The deployed applications like OHS, WLS_FORMS, WLS_REPORTS binaries are upgraded to the latest version
WebLogic startup scripts/configuration files are amended with the latest Fusion Middleware paths & references
What this means to you? Well, you will have two different Oracle Homes for WebLogic , co-existing to serve you the purpose. You cannot uninstall the WebLogic 12.2.1 or 126.96.36.199 once the upgrade processes are over ;)
In addition to the above, I believe, the whole upgrade process is intended to upgrade ONLY the server side components for the domain, not the development elements.
(Please note, I’ve reached to the above conclusion once after analyzing almost all WebLogic startup scripts and configuration files, None of the Oracle documents available as on date confirms to this findings of mine and I am the ONLY one responsible for what I just said ;) )
Let us upgrade!
Oracle document 12c (188.8.131.52.0) E80069-02 suggests the following for upgrade
184.108.40.206 Running the Upgrade Assistant to upgrade the Domain Schema
Perform the steps required to run the 220.127.116.11.0 Upgrade Assistant for upgrading the
To upgrade the Domain Schema:
1. Run the 18.104.22.168.0 Upgrade Assistant from the following location:
This means you have to switch to “D:\Weblogic12213\Middleware\Oracle_Home\oracle_common\upgrade\bin” & execute ua.bat file
2. Select the All Schemas Used by the Domain option.
3. Select the Schema components to Upgrade.
4. Provide the location of the reconfigured 12c domain.
(Point to the domain that is still under your Weblogic 12c 22.214.171.124.0 install folder or the physical location where it was created.)
5. Select the prerequisite check boxes
6. Provide the RCU Database connection information.
7. Click Next.
8. Click Finish.
126.96.36.199 Reconfiguring the 12.2.1 Domain using the WLS Reconfiguration
You have to reconfigure the 12.2.1 Domain using the WLS Reconfiguration Wizard.
To reconfigure the 12.2.1 Domain:
1. Run the Reconfiguration Wizard from the following location:
2. Provide the location of the 12.2.1 FMW Domain for upgrade.
3. Enter the RCU schema information.
4. Select only the Topology option in the Advanced Configuration in the
Do not select the System Components option. Those will be automatically
configured/upgraded by the Upgrade Assistant.
5. Leave the default selections on the Node Manager screen. Enter user name and
password if needed.
6. Select JRF-MAN-SVR and FORMS-MAN-SVR server groups for all the Forms managed servers, including the default Forms managed servers WLS_FORMS, WLS_FORMS1, etc., and any other Forms managed servers users that may have been added after the 11g installation. (You can safely avoid this)
7. Click Next until you get to the last screen of the Reconfiguration Wizard.
188.8.131.52 Running the Upgrade Assistant to upgrade the Forms installation
You have complete series of steps by using the 184.108.40.206.0 Upgrade Assistant to
upgrade the Forms installation.
To upgrade the Forms installation:
1. Run the 220.127.116.11.0 Upgrade Assistant from the following location:
2. Select the All Configuration Used by the Domain option.
3. Provide the location of the reconfigured 18.104.22.168.0 domain.
4. Select the prerequisite check boxes.
5. Click Upgrade.
I really hope, the above Oracle instructions are simple to follow & one with minimum experience setting up Oracle software should able to complete the activities without any failure.
The entire exercises should be completed within 30-40 minutes. Once the upgrade process is over, you can start the Node Manager and Weblogic Admin server to confirm the components were upgraded to 22.214.171.124.0
Mine were, so I hope you will also have the same experience.
The real dilemma starts from here. Although all the components are upgraded, none of your forms modules would load and present you the following error:
FRM-40011: Form was created by an old version of Oracle Form. This means, your forms modules which were compiled using Forms 12c 126.96.36.199.0 are not compatible with 188.8.131.52.0 & YOU MUST recompile all your existing forms/menus/libraries using the latest version of Oracle forms!
To your utter dismay, you will find that, the forms builder with your upgraded domain is NOT upgraded to 184.108.40.206.0, instead it still remains 220.127.116.11.0, which is of no use as the forms server application has already been upgraded.
This could pose different levels of difficulties while deploying the applications. I have figured out the following in my case
I cannot recompile the forms modules to latest supported version from the same box.
If I am developing the application on a Windows Machine and moving it to Linux environment, I will not able to compile the modules as the stack that is available with the environment will be still 18.104.22.168.0 & I am expecting to get the same “Form was created by an old version of Oracle Form” errors!
Initiate another Forms & Reports installation & choose a new “HOME” for the installation and select “Standalone forms”.
Refer this wonderful document for details, if you don’t have experience with setting up standalone forms developer instances
Add the connection details to the tnsnames.ora file available with your Standalone Forms Builder instance folder & you are all set to go. Now you can recompile the modules and go online with the supported version of forms. I didn’t check the reports part yet, I may in couple of days time & will update this post accordingly.
Well, this workaround shouldn’t be the ONLY one solution. I opted it due to the fact that I couldn’t figure out anything else and wanted to complete a migration urgently for demonstration purposes.
That’s all folks, I hope you would find the crude way of getting things done helpful in an emergency situation ;)
While creating a new order management transaction type & defining sequence number, we were hit by the error “ORA-20001: APP-FND-01728: An assignment does not exist for these parameters”
Oracle has couple of documents addressing this error
ORA-20001: APP-FND-01728: An assignment does not exist for these parameters (Doc ID 2275689.1)
Order Import Does Not Create Orders, errors errors ORA-20001: APP-FND-01702 (Doc ID 1298436.1)
In our case, both these documents were not of much help. After long hours, we rectified this error to wrong selection of LEDGER while the document sequence was assigned to the newly created transaction type.
So, if the above documents are not of much help for you as well, do check the LEDGER assignment & correct it.