Form Builder crashes on recompile

user1292445

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

Frank Hoffmann

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

Yes I did.

Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production

Version 19.10.0.0.0

Frank Hoffmann

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

@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

https://community.oracle.com/tech/developers/discussion/comment/16786158#Comment_16786158

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

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

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

@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

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

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

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

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

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.