Forms 5.0: Changing relations and FRM-15004 Error while parsing join condition.

From: Rolf Unger <rolf.unger_at_ctilabs.de>
Date: 19 Feb 2002 02:09:05 -0800
Message-ID: <32fe19ad.0202190209.58736551_at_posting.google.com>



Hello,
I got some problems with a Oracle Forms 5.0 Application:

I have a relation for a data block BLOCK_B in my form.

I don't know excatly how this relation was made up. My assumption is that the canvas and the datablocks were generated with the DATA Wizard and that the wizard evaluated the foreign key constraints on the tables that are used as datasource for the two blocks.
Actually I jumped in this project, when the fmb file was already 2 MByte big.

The following is the old constellation of tables related with a foreign key, that was used initially by the Forms Data Wizard for creating the data block and its relations.



 Old Tables

TABLE table_a
 ACCOUNT_NO	 NOT NULL NUMBER(20) <-.  unique
 SERIAL_NO	 NOT NULL NUMBER(10)   |  primary key
 ATTRIBUT_A		  VARCHAR2(20) |
 ATTRIBUT_B		  VARCHAR2(25) |
                                       |
TABLE table_b                          |
 ACCOUNT_NO	 NOT NULL NUMBER(20) --' Foreign Key constraint
 ATTRIBUT_C		  NUMBER(1)
 ATTRIBUT_D		  NUMBER(4)

and the first records of table_b:

ACCOUNT_NO ATT_C ATT_D
---------- ----- ---------

   3474234    33         1
   9273762    49         1
   2734521    94         2

The properties for the relation in the object navigator shows as join condition:

     BLOCK_A.ACCOUNT_NO = BLOCK_B.ACCOUNT_NO Now I realised that the column SERIAL_NO is more useful in both tables (ACCOUNT_NO is unique but random, SERIAL_NO is unique and sequential) and changed the tables in the database. Actually I replaced the key column ACCOUNT_NO in table_b with the sequential serial_no column (table_a is not changed):



 New Tables

TABLE table_a
 ACCOUNT_NO	 NOT NULL NUMBER(20)     unique
 SERIAL_NO	 NOT NULL NUMBER(10) <-. primary key
 ATTRIBUT_A		  VARCHAR2(20) |
 ATTRIBUT_B		  VARCHAR2(25) |
                                       |
TABLE table_b                          |
 SERIAL_NO	 NOT NULL NUMBER(10) --' Foreign Key constraint
 ATTRIBUT_C		  NUMBER(1)
 ATTRIBUT_D		  NUMBER(4)

The first lines of table_b are now:

 SERIAL_NO ATT_C ATT_D
---------- ----- ---------

         1    33         1
         2    49         1
         3    94         2

Obviously if I compile the Forms Application against the changed database, I get lots of

            bad bind variable BLOCK_B.ACCOUNT_NO
            identifier ACCOUNT_NO must be declared
errors.

So I go through the error list, changing most of the references to account_no or :BLOCK_B.ACCOUNT_NO to ...serial_no. After cursing the poorly builtin PL/SQL-Editor for the hundredth time I can compile my forms application without errors. So I feel brave enough to adjust the relations of the several datablocks also:
But whenever I try to change the join condition of a relation object, to

      BLOCK_A.SERIAL_NO = BLOCK_B.SERIAL_NO I get

      FRM-15004 Error while parsing join condition.

and Forms insists on keeping the senseless

     BLOCK_A.ACCOUNT_NO = BLOCK_B.ACCOUNT_NO I look again on block_a: Yes, I have there a 'ACCOUNT_NO' and a 'SERIAL_NO', and in block_b I see only a 'SERIAL_NO' perfectly mirroring the columns of the table TABLE_B.

So does this mean I cannot change an existing relation, but have to delete and re-create it ?
Or do I have to delete the complete block, and rebuild it with the Data Wizard? How can I preserve the graphical design of my canvases in that circumstances? I really don't won't to drag'n'click again those labels, sizes of text fields, etc ...

BTW, I'm using Developer 2000 R2.1, so it should be Forms 5.0.6.8, at least that's what the installer tells me.

So that's my practical problem. I appriciate any help on this topic.

It can also be:
"You have an FMB of 2 Megs? Then your design is
 terribly wrong. Restart from scratch, split it in several parts,  use some 'call_form()',..."
or
"Why are you using forms? It has no useful revision control system.
  What can you do with a 9 MByte FMT ASCII file? You can hardly run   a diff on it."
  And if you finally through it it will display something like

  • 00000031 00000009 00000080 80010509 00002422 0000050f 001f0000 000e4355
  • 53545f50 524f465f 54595045 00000000 000004af 50524f43 45445552 45206375 + 00000031 00000009 00000080 80010509 00002422 0000050f 001f0000 000e4351 + 53545f50 524f465f 54595045 00000000 000004af 50524543 45445552 45207175

where you actually expect to see something more readable:

  DECLARE

+    v_dummy         number;
     v_button        number;

These are just some suspicions I carry around with me for the last few months. As I said, I'm would also be thankful, if you just confirm these, though it would mean that the pain of the last months was in vain and that I have to look for another tool.

Another minus is that there is no documentation available how to maintain Forms Project.
Anything, that I've seen (including the online help) is of the type: "Let's start with a simple case, you have to tables ... click on ..  to activate the Data Wizard ..."
Even in Lulushi's Prentice Hall "Forms Developer's Handbook" I find only the remark that the properties of a relation object can be changed. Examples for using call_form() are also hard to find.

Maybe I should stop complaining ... ;-\

Well, I did a search on the relation topic with Google, and found the similar problem
"Forms 5.0 and FRM-15004: Error while parsing join condition"   posted on 10 Sep 1998 by Todd Owers
(1 article only, no response ... )
Hm, the world's knowledge is said to be doubled every 2 years in the current internet times. So no reason to give up hope.

Thanx in advance for your help,

Rolf. Received on Tue Feb 19 2002 - 11:09:05 CET

Original text of this message