Today I manually added items to a block in a form, but I forgot to place them in the right order. They were added at the bottom of the block, but somewhere in the middle of my screen (in the layout editor). After saving the values at runtime, somehow, the values ended up in the wrong boxes!
After correcting the order in the block this issue was solved.
Archive for the ‘Forms 10g’ Category
Forms: the order of items in a block
Monday, June 15th, 2009block status-”CHANGED” after post-query trigger fills nondatabase items
Thursday, November 1st, 2007A very annoying bug that has apparently been around for ages and never been solved:
When you have a lookup field (nondatabase) with an LOV and set ‘validate-from-lov’ to true, your blockstatus is set to ‘CHANGED’ when you fill the lookup in the post_query trigger.
This is silly because you are changing nondatabase items. The following post shows that this has been a problem since 2000:
http://forums.oracle.com/forums/thread.jspa?messageID=253582
I found a document on metalink about this, which is dated 31 oct 2007.
I tested the solution provided in the document and it works!
Compile all your forms at once
Friday, September 28th, 2007This is the script I use to compile all forms in a directory using ifcmp90.
set ORACLE_HOME=c:oracle10gdevsuite
for %%p in (”*.fmb”) do c:oracle10gdevsuitebinifcmp90 module=.%%p module_type=form userid=
don’t forget the ORACLE_HOME bit, if it is not set correctly you might end up with an ORA-12538: No such protocol adapter
ora-12538
Friday, September 28th, 2007I have this script that uses ifcmp90 to compile all forms in one directory. I sometimes need it when I change a library, but lately it has been failing me with an ORA-12538: No such protocol adapter. I had been fiddling around with my oracle homes and apparently I broke this.
It turned out that the error occurs when you have your oracle_home environment variable not set correctly. It is usually set to the home of the database but for ifcmp90 i needed to set it to the devsuite home.
This solved it
FRM-40506: Oracle error: unable to check for record uniqueness
Friday, April 13th, 2007I run into this problemevery now and then and I keep forgetting how to solve it. Here it is:
If you have a block based on a table, and the primary key is automatically filled with a database trigger, do not set “Enforce primary key” to YES for the block.
Existing state of … has been invalidated
Monday, March 27th, 2006I get this error every now and then when I push a button in a Form to run a report on a view that bases its where clause on variables in a package (think of usernames, dates etc), even though in TOAD all my views and packages are valid, and running the report from the builder works just fine too.
Usually trying again compiles the package and makes it work, but not this time. After trying all sort of things, restarting the reports server did the trick. No idea why though, the reports server makes a new connection for every report, so it’s not pooling that causes this.
no_data_found error when trying to upload files using WEBUTIL
Thursday, January 19th, 2006When you use WEBUTIL in Forms or Designer to upload files to the database, you might get the ORA-01403 : no_data_found error when you’ve first installed the lot and try to upload a file,
even when there was no query to the database that could have caused it.
When this happens, recompile the webutil.pll file on the target machine, this solved it for me.
Compiling forms on linux (no graphical interface)
Wednesday, January 4th, 2006Today someone needed my help compiling forms under linux. We tried compiling whilst being logged in with Putty, but received the following error:
FRM-91500: Unable to start/complete the build.
Metalink came up with note 266731.1 which was too much of a hassle for me to read (I prefer short and concise solutions) and so I searched the oracle forums and found this:
http://forums.oracle.com/forums/thread.jspa?messageID=697343
The solution was as follows:
export TERM=vt220
export DISPLAY=:0.0
frmcmp.sh module=
and voila!
Prompts and Canvases
Tuesday, December 27th, 2005Tip:
When you are in the layout editor and you are changing a prompt, do not change the canvas in the dropdown when the cursor is still in the prompt, Forms does not like that…..
PRE-BLOCK trigger
Tuesday, December 27th, 2005I have a form in which I reuse the window. I have 5 canvases, each contain a block. On the first canvas I have 4 buttons to navigate to the blocks. This is what happens:
- I enter the form
- I press the first button to go to the second block
- First, the PRE-BLOCK trigger of the second block fires
- Then the WHEN-BUTTON-PRESSED trigger of the first button fires
- Then the PRE-BLOCK trigger of the third block fires (!)
- Then the PRE-BLOCK trigger of the fourth block fires (!)
- Then the PRE-BLOCK trigger of the fifth block fires (!)
- Then the PRE-BLOCK trigger of the second block fires again (!!!)
This only happens once, no matter which button I press. When I navigate back to my original block and then press another of the 4 buttons, only the PRE-BLOCK of that particular block fires and after that the WHEN-BUTTON-PRESSED trigger and that’s it.
I ran into this trying to change the window title in the WHEN-BUTTON-PRESSED trigger of the button and the PRE-BLOCK trigger kindly changed it back because it was fired before and after the WHEN-BUTTON-PRESSED trigger….
I have posted this on OTN here.
[Update 28-12-2005]
I found out that the generator preference BSCSCP is not implemented consistently in the Designer library.
I created a Service Request (They are no longer called TARs) in which it said this:
Situation:
One form, one window with 5 canvases on top of eachother. When one is visible the rest is not. First canvas contains the master block, the other 4 contain detail blocks, all on the same level (directly under the master).
The first canvas has 4 buttons to navigate to the other 4, the 4 other canvases have one button to navigate back to the first canvas.
Generator preferences:
BSCSCP: F
BSMOFF: E
BSMON: A
BSQENP: Y
When starting the form the following happens:
- the on-populate-details query does not query the details, because the 4 canvases are not visible.
- the when-new-block-instance trigger is fired, calls CGBS$NEW_BLOCK but since P_TO_BLOCK is equal to CGBS2$.GET_NAV_FROM_BLOCK it does nothing.
All detail blocks are NONCOORDINATED.
Conclusion: details are not queried. This is the behavior I want.
When using one of the buttons to navigate to another canvas, the following happens:
- the when-new-block-instance trigger fires, and since P_TO_BLOCK != CGBS2$.GET_NAV_FROM_BLOCK, CGBS$.COORD_VISIBLE_BLKS(P_TO_BLOCK) is called.
This procedure loops through all blocks, and for the NONCOORDINATED blocks (there are 4 of these now) it does roughly the same
as in the ON-POPULATE-DETAILS trigger, BUT on line 80 of package CGBS$ this line is different:
CGBS2$.GET_BLOCK_WINDOW(current_block) = event_window
My form has one window, which makes this condition true at all times and which means that for all 4 detail blocks the
details are queried, even when the canvas they are on is not visible.
What I expected was that Only the block I navigating to is queried, and the others are not, until I navigate to them.
The result of this behavior is that the block triggers for all blocks are fired which results in unwanted behavior.
For example, the title of the window is changed in the when-new-block-instance trigger, and thus wrongly set.
After this, all details have been queried, all blocks are COORDINATED and behavior is as expected, until a different row
in the master block is selected and the whole process starts over.
I think that the following code (lines 76-84, CGBS$COORD_VISIBLE_BLKS)
elsif ( CGBS2$.GET_COORD_STYLE = ‘F’ )
then
if ( CGBS2$.IS_TREE_VISIBLE(current_block)
or
CGBS2$.GET_BLOCK_WINDOW(current_block) = event_window
)
then
CGBS$.QRY_ONE_BLK(current_block);
end if;
should actually be
elsif ( CGBS2$.GET_COORD_STYLE = ‘F’ )
then
if ( CGBS2$.IS_TREE_VISIBLE(current_block) )
then
CGBS$.QRY_ONE_BLK(current_block);
end if;
Like it is in CGBS$COORD_RELATION (lines 451-463)
(My apologies if the line numbers don’t match, I used Textpad to determine them)
Which describes best what I have found so far.
I will update this post when Oracle have contacted me…..
[update]
Oracle have admitted that the code is not consistent, but no patch will be written because it could affect too many applications already relying on this behavior. I left it at that since it’s not really important anyway