This discussion is archived
7 Replies Latest reply: Jun 21, 2013 2:13 AM by user8950953 RSS

Forms crash/throw forms errors when fmx is copied from one environment to another.

user8950953 Newbie
Currently Being Moderated

Hello,

 

Forms version 11g R2

 

We have 2 environments, Test and Production. When fmx are copied from UAT to Production, some programs work, some throw forms errors. It works fine if the program is compiled in Production.

Should the forms be compiled in respective environments for it to work fine?

Or is there a way to address this issue?

 

General question:

What would be the best method to release forms?

 

Appreciate any help.

 

Regards

Ajith

  • 1. Re: Forms crash/throw forms errors when fmx is copied from one environment to another.
    InoL Guru
    Currently Being Moderated

    You didn't mention the OS on which Forms is running.

    Generally speaking, if the OS versions (for development, test and production) are not the same, you need to recompile in each environment.

     

    I know that for Windows, most of the times just copying the fmx files will work. However, if you do experience problems, just recompile.

  • 2. Re: Forms crash/throw forms errors when fmx is copied from one environment to another.
    Christian Erlinger Guru
    Currently Being Moderated

    It would be interesting to know the exact errors you get...? Depending on the errors you get there might be other ways except a recompile. If the OS Platforms are completely different there is no other way, but if you are getting e.g. an ORA-4062 signature of XYZ has been changed you probably did something like using %ROWTYPE records in Forms etc. This can be fixed by compiling against the Target database or by simply not using such constructs...

     

    Oracle recommends to recompile your forms on the target platform against the target database, but by having some do's and dont's in mind you could avoid that.

     

    cheers

  • 3. Re: Forms crash/throw forms errors when fmx is copied from one environment to another.
    lake Journeyer
    Currently Being Moderated

    I believe it was previously established that you had to compile the form on the platform from whence it is served.

    This is particularly the case if it was developed on 32 bit windows and you are deploying on a 64 bit machine.

    Recompile them would be my advice.

  • 4. Re: Forms crash/throw forms errors when fmx is copied from one environment to another.
    user8950953 Newbie
    Currently Being Moderated

    Thank you all.

     

    The OS is Windows 2008 32 bit. Both environments are identical.

    The errors I get are various and different in different forms. Most frequently seen examples, 40741 - Unable to locate record 2 on block BLOCK_DETAIL, WHEN-BUTTON-PRESSED trigger raised unhandled exception ORA-06508 - (40735)

     

    Though ORA-06508 says a program unit is missing, all db programs were available and in a compiled state. Both errors disappeared after compiling the form in the respective environment.

     

    It is new learning that %ROWTYPE can create problem. Thanks.

     

    All reports works fine. Never gave a problem when copying the .rep.

     

    I could not find much information on this on internet. Guess most preferred option is compiling in all programs in the respective environment.

     

    Wonder how products based on Oracle forms are released to large number of customers. Earlier we could make a install (build) with Oracle Project Builder. Now we execute db scripts and batch compile forms manually. Is there a way to make a build and deploy like a installer program for 11g?

     

    Thanks

    Ajith

  • 5. Re: Forms crash/throw forms errors when fmx is copied from one environment to another.
    Christian Erlinger Guru
    Currently Being Moderated

    As already said Oracle recommends to recompile against on the target IAS against the target database. However this might not be as desireable if you have 100+ customers with who knows how many systems (test, prod, whatever else) out there like us. For every customer this at least would mean 2 recompiles. As for now our build process for forms lasts 2 hours (for one version; we have 10g single byte, 10g AL32UTF8 and 11g AL32UTF8), so when doing this at installation time this might not be nice.

     

    As already said if you are careful you won't have to recompile, but of course you have some limitations (if you want to spare yourself compile orgies with different combinations of target OS/db charactersets etc.)

    - limit the OS versions you support

    - the database characterset is crucial; if you have several charactersets out in production which do not play well together think about going to AL32UTF8 or else you'll have to compile against each characterset you support

    - don't use %ROWTYPE constructs or select * from (....) constructs in your forms

    - be especially careful with the NLS settings (I am thinking of NLS_LANG and NLS_LENGTH_SEMANTICS) at compile time and at runtime and even at database install time. I remember having a crashing forms 10g runtime with NLS_NCHAR_CHARSET=UTF8 even though we didn't use the national characterset at all but it was simply the way the database was installed (gladly the NCHAR_CHARSET can be changed quite easily if you don't use it).

     

    It took us some headaches but as for now we have a compile once run everywhere solution (with 3 installers for forms 10g and 11g with the respective charactersets); We implemented a build routine which makes sure all things are correct at compile time and an install/database update tool which makes sure the installation is correct to avoid human errors. To avoid troubles caused by different database or forms installations you can use the silent installation option of OUI and feed it with given database templates and response files to make sure your settings are correct.

     

    If you just have one application on one or two of your servers this isn't worth the trouble; however if you have a lot of customers out there (with maybe also embedded licensing like we do) you might think about standardising your install/build/deploy mechanisms as in the long time it will save you a lot of trouble. I have to say I haven't seen a ORA-4062 and their companions out in production for quite a while, and we are doing the compile once run everywhere for quite a while

     

    You of course have to bear in mind that oracle recommends recompiling; so if you hit a problem which can be fixed by a recompile Oracle Support will tell you to do so.

     

    cheers

  • 6. Re: Forms crash/throw forms errors when fmx is copied from one environment to another.
    Christian Erlinger Guru
    Currently Being Moderated

    Oh, and I forgot:

    - never ever directly reference SYS objects (like e.g. utl_abcd, dbms_xyz, v$asdf or what ever else) as they might change even with database patchsets (adding a default paramter to a procedure for example) which basically will make your forms application work with one patchset but failing with another one (depending on the patchset of the database you compile against). Better yet wrap the procedures you need in your very own database procedures and call those procedures.

     

    cheers

  • 7. Re: Forms crash/throw forms errors when fmx is copied from one environment to another.
    user8950953 Newbie
    Currently Being Moderated

    Thank you for the elaborate reply. Looks like we have lot of work to do before switching to compile once run everywhere. I guess the best way now is to compile the forms everywhere.

     

    Thanks

    Ajith

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points