Forum Stats

  • 3,722,809 Users
  • 2,244,417 Discussions
  • 7,850,109 Comments

Discussions

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Form Builder crashes on recompile

user1292445
user1292445 Member Posts: 4 Blue Ribbon

I have a problem with my Form Builder 12.2.1.4 (same effect with Form Builder 12.2.1.3) when recompile against database schemas based on 19.0.0.0. (now 19.9.0.0)

I connect to the database and develop and all works fine up to the point I do changes on the database schema. When I recompile, the form Builder freezes and crashes down without an error. I have tried it with container based databases and with no container databases and with Form Builders on different machines. All have the same behaviour.

I have tried different solutions. I installed database patch 30210429, 26003708 and the January RDBMS patchsets. I explicitly set the FORMS_PLSQL_BHVR_COMMON_SQL to false on the machine with the form builder. But the Problem still exists.

Can anybody help and has a solution for this problem?

THX

Answers

  • Frank Hoffmann
    Frank Hoffmann Member Posts: 768 Gold Badge

    Did you patch you database to 19.10? This will very likely solve your problem. It is a database bug and not a forms bug.

  • user1292445
    user1292445 Member Posts: 4 Blue Ribbon

    Yes I did.


    Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production

    Version 19.10.0.0.0

  • Frank Hoffmann
    Frank Hoffmann Member Posts: 768 Gold Badge
    edited February 23

    now 19.9.0.0 ?

    We installed patch 26003708 on the Forms Builder with this workaround on Forms 12.2.1.4

    Rollback 30220086

    Install 29831650

    Install 26003708

    plus January Patch 19.10 on the database

  • Michael Ferrante-Oracle
    Michael Ferrante-Oracle Member Posts: 6,490 Employee

    @user1292445

    You said:

    ...I explicitly set the FORMS_PLSQL_BHVR_COMMON_SQL to false...

    FALSE (0) is the default, so setting this would result in no change. Setting this to 1 (TRUE) will enable the "common" parser rather than the old parser. Also, if your code uses COMMIT, all occurrences should be changed to COMMIT_FORM.

  • user1292445
    user1292445 Member Posts: 4 Blue Ribbon


    Sorry 19.9 is incorrect, it was my mistake, its 19.10.0.0


    Let me explain my development structure:

    I have an forms develoment manchine, based on Windows 10, with installed Form Builder 12.2.1.4 and a database behind with Version 19.3 This database I do not use, it is only for the schemas, which I need to run forms and reports builder. The only thing on this machine was: setting FORMS_PLSQL_BHVR_COMMON_SQL to false. There are no more patches installed.

    Then I have a database server based on linux with all development database. This one has Version 19.10.0.0 and is patched with 26003708, 30210429 and 26003708.

    I do not exactly read from your answer, where I should install the patch. So I am a little bit confused.

    Where the patches should be installed? Is the machine with the Form Builder? Should I patch the database that holds all the schemas which I need to run Forms? But on the other hand, with Form Builder 12.2.1.3 we have the same problem with freezing in when developing against 19.10.0.0 and when connecting to databases 11.x or 12.x we do not have problems.

    If not so, so I have to patch my database server that holds all my application-schemas and is patched before start of this topic with 26003708, 30210429 and 26003708


    THX

  • Frank Hoffmann
    Frank Hoffmann Member Posts: 768 Gold Badge
    edited February 24

    The January Patch (19.10) has to be installed on the database.

    The other patches on the Forms Builder (Windows):

    We installed patch 26003708 on the Forms Builder with this workaround on Forms 12.2.1.4

    Rollback 30220086

    Install 29831650

    Install 26003708


    Did you check the hint from Mike with the parameter? We are not using this parameter.


    Frank

  • user1292445
    user1292445 Member Posts: 4 Blue Ribbon

    I checked this Parameter, yes. I thougth, installing that parameter will helps with the problem, sometimes helps when adding registry parameters, but not in this case. So I would delete this parameter again.

    So I try to patch the form builder machine and will give a feedback

    THX.

  • Michael Ferrante-Oracle
    Michael Ferrante-Oracle Member Posts: 6,490 Employee

    @user1292445

    I think you misread what I said. Again you said,

    The only thing on this machine was: setting FORMS_PLSQL_BHVR_COMMON_SQLto false.

    In the Registry, set FORMS_PLSQL_BHVR_COMMON_SQL to TRUE or 1. Exit the Builder then reopen and retest.

    If none of what has been suggested here helps, you should probably contact Support. They will want a test case that they can load and compile in the Builder, so be sure the test case is NOT based on your database objects. Instead, try to create a test case on a demo scheme like SCOTT or other Oracle demo schema that Support will have available to them.

  • eliasfm
    eliasfm Member Posts: 26 Bronze Badge

    Hello

    When I have problems like that I test this: Open forms builder and disconnect from database. Recompile with mays+Ctrl+k. Ignore errors an save fmb. Restart builder, reopen fmb and recompile connected to database.

    Regards

  • sigrid
    sigrid Member Posts: 23 Blue Ribbon

    Hello

    I have the same problem with the following constellation. The database for the form builder version 12.2.1.4 is an Oracle database 19.3 without any patches. The database for the application data is a version 19.10 database.

    The form builder crashes when database objects are changed in the application database, e.g. the signature of a procedure is changed, and these changes are then used in the form builder without reconnect in to the database and compiling the form.

    It is annoying to have to reconnect in to the database every time you make such a change.

    Unfortunately I could not find patch 26003708 for version 19.

    How can I solve the problem? Does the database for the form builder also have to be a oracle database 19.10?

    Best regards

  • Michael Ferrante-Oracle
    Michael Ferrante-Oracle Member Posts: 6,490 Employee
    edited March 22

    At very quick glance, this was a fix in the middletier. Therefore, you need to install the latest DB patch to your mid tier. For Forms 12.2.1.4 the Patch ID is as follows:

    For Windows mid tiers: Patch 32000405 (you will likely need to rollback 29831650 first)

    For Unix/Linux: Patch 31985579

    Contact Oracle Support if you have problems obtaining the patch or installing it.

  • sigrid
    sigrid Member Posts: 23 Blue Ribbon

    Hello Michael,

    thank you for the answer. I am a bit irritated though. The patch 32000405 is a database patch for the version 12.1.0.2.210119. But the database version for the Forms Server is a 19.3 (supported according to the certification matrix).

    So I can't apply this patch. Or do I understand something wrong?

    Or should I rather use patch 32062765 for the middletier database?

    Best regards

  • Michael Ferrante-Oracle
    Michael Ferrante-Oracle Member Posts: 6,490 Employee

    I realize it's sometime difficult to understand the architecture of the FMW stack, as it is fairly complex. However, if you consider it from a higher level it might be more clear. Consider this; the FMW stack that includes Forms also includes many other sub-components. Some are independent of Forms while others are direct dependencies for Forms (and others). For example, the PL/SQL language is actually a database technology and Forms requires it in order to allow you to developer with it in the Form Builder. The networking technology that allows Forms, Reports, SqlPlus, SqlDeveloper, and others to connect to the database belongs to the database. And so on...

    In the case of the FMW stack, because of these DB dependencies, the FMW stack includes a variety of Database technologies within it. In the case of the FMW 12.2.1.4 stack, it includes components from the DB 12.1.0.2 client. Don't be confused though. This is not the same as the DB Client software you would typically install separately.

    So, in cases where there is a bug, security issue, enhancement or other code change needed in the DB client layer, it is not uncommon to apply a DB patch to the FMW stack. However, it is very important that you NOT attempt to change the major DB version within FMW. Doing so would break the installation. So when you need to apply a DB patch to FMW 12.2.1.4, the only DB version you would use are those designed for 12.1.0.2. Other FMW versions use different DB versions.

    With that in mind, no you cannot install 32062765 to the middle tier because that is a patch for DB 19. The latest DB patch that would be compatible in FMW 12.2.1.4 would be 32000405, which is what I mentioned previously.

Sign In or Register to comment.