Toad Issue backspace key not working

Note :
- Click the image to see more larger image on the TOAD temp folder location.

Hot News :

backspace not working in toad, backspace is not working in toad, arrow keys not working in Toad, toad backspace key not working, backspace key not working in toad, BACKSPACE, cannot backspace in toad, backspace doesn\t work in toad, backspace doesnt work in toad, toad for oracle backspace not working

Join Configuration Cannot Be Resolved Message

A. This is caused by a conflict between the default settings in Discoverer, and the data that the University wishes to hold in the Business Intelligence Database

and mention this “magic” word :

It is very easily resolved:

Wow, i’m so thrilled to see the next step how to resolve this error…(i am so sure you either)

So here are the steps that you need to follow in order to fix this Discoverer BI warning message :
1. Open Discoverer Plus (not Viewer) and close the Wizard asking you to create new/open existing workbook
2. On the File Menu, go to Tools, Options
3. Click the Advanced tab
4. Check the second checkbox down, “Disable fan-trap detection”

I am sure you can open the report now.

So what is this Fan-Trap Detection actually?

A fan-trap occurs when the data items in two folders are not directly related (such as with a Customer ID), but do have a relationship based on the data items in a third folder.

As example : you have 3 folder that you want to pick up the fields. Just named it Folder A, B and C.
Folder A and B don’t have direct relationships build in the Discoverer Administrator, but Folder A and C have the join relationships also with folder B and C. Then you try to get the fields from those 3 folders. You get what i mean?

Discoverer will automatically detects and resolves potential fan trap queries into multiple SQL statements to obtain normal expected results. If the Discoverer cannot resolve a fan trap, Discoverer prevents the worksheet from being running and then displays the warning error message dialog.

Just keep in your mind that if you disable fan trap detection, Discoverer still detects potential fan trap configurations, and resolves them by generating the correct SQL and displaying correct worksheet data. If Discoverer cannot resolve a fan trap, it displays the worksheet data and does not display a warning message dialog. The result of disabling fan trap detection might result in a query based on an unresolvable fan trap configuration, generating potentially misleading results.

So its actually depend on what you want to do. I suggest you better fix the relationships between those folders and try run your workbook again. So it would save in case of misleading data results in your workbook.

If you want to see more information about this fan traps, try see your Oracle Application Server Discoverer Plus User’s Guide. But i believe that we to “busy” open the user guides

Hot News :

join configuration cannot be resolved discoverer, Join configuration cannot be resolved Reason: more than 1 of the detail folders uses non-aggregated items Attempt to open workbook failed, join configuration cannot be resolved reason more than 1, join configuration cannot be resolved oracle discoverer, Join configuration cannot be resolved Reason: more than 1 of the detail folders uses non-aggregated items, join configuration cannot be resolved in discoverer, join configuration cannot resolved oracle discoverer, discoverer join configuration cannot be resolved, oracle discoverer error message, Configuration cannot be resolved

FRM-40654

As summary, my form blocks condition were like this :
BLOCK1 = TABLE_A
use set_block_property on pre_query trigger to change the query_data_source_name to TABLE_X.

Everything looks fine when i load the form, but when i tried to change the field value, it gave me this form error FRM-40654. I search around in Google and only can found several peoples face the same frm-40654 but in different situation.

Some people said its because of the record has been lock somehow and need to released first. Its correct somehow, but not in my case here. After hassle try this and that for several hours… (really wasting time..) then EUREKA … need to set this property as well dml_data_target_name in the pre-query trigger.

set_block_property(‘BLOCK1′,dml_data_target_name,’TABLE_X’)

I hope this can save most of your time rather than finding the causes by your self, might my experience help you reduce your hassle.

Hot News :

frm-40654, set_block_property, frm 40654, set_block_property query, query_data_source_name set_block_property, set_block_property in oracle forms, oracle set_block_property, set block property, set_block_property(‘BLOCK1′ dml_data_target_name ’TABLE_X’), oracle forms FRM-40654