• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2931
  • Last Modified:

Can I retrieve the where clause Oracle generates from the Enter/Execute query buttons

When a user goes into 'Enter Query' mode, enters some form criteria, and then presses 'Execute Query', is there a way to retrieve the where clause Oracle generates against the data block?
  • 4
  • 3
1 Solution
Oracle doesn't use a where clause against the data block, the where clause is against the objects (the sql execution engine / optimizer) but as far as retrieving the SQL the user submitted, you can find it multiple ways (besides if Oracle forms gives you an option, as I haven't done forms in years).

1) You can use the V$SQLAREA manually to check queries
2) You can use general auditing
3) You can use FGA (Fine Grained Auditing) against the specific tables or schemas or even for specific users

V$SQLAREA is a view that will contain all SQL being run in the instance, and requires no setup. (select sql_text from v$sqlarea) or if the sql is larger than 1k, use sql_fulltext field which is a clob.

FGA requires a bit of setup, but its eaasy and is my preferred route. If you want to go that route, I can provide info on how to set it up with 10g and up.

As to a Form's specific option, I will let a Forms guru add that as I am not sure.
See the bottom of this thread where we provide examples of setting up FGA to audit an object

iamlooperAuthor Commented:
Thanks mrjoltcola. Let me clarify the reason I want to capture the users query condition. Very simply, if the user queries some records out using Enter_Query and Execute_query, I want to be able to re-execute the form at a later time and retrieve the same records.  

I have a text box on the form where a custom where clause can be typed in, and then executed to 'Filter' the form records. I also want to give the user the option to use Oracles built in Query-By-form tools (Enter_Query / Execute_Query) to filter the records. Ideally I would like to populate the custom where clause text box on the form with the results of the Enter_Query. I can then re-execute the same query condition whenever needed.

The ultimate reason I want to be able to store the where condition is because when the user is looking at a record on the form, they may choose to run some updates using server side procedures, which change the current record being displayed. The only way I know of to get the form to reflect the external changes made to the record, is to save the current block record number, re-execute the query, then go back to the saved record number. If the user had used ENTER_QUERY, then re-executing the form retrieves all records with no filter condition, and the record number is no longer valid. I want to re-execute with the same ENTER_QUERY clause used initially.

If there is a way to refresh the current form record being displayed without re-executing the data block, then that would be a useful solution. Although I would still love to capture the Enter_Query condition to populate the custom where clause text box. I investigated using KEY_ENTQRY and KEY_EXEQRY a while back to see if I could intercept what the user had entered so that I could build a where clause up myself, but could'nt seem to get it working. At the time I thought that I was very close, but maybe just missing a key point somewhere.

Cloud Class® Course: Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

So the Oracle form interface and the service side procedure are running in different sessions?

Why can't you integrate those procedures into your form? Are they PL/SQL?

Otherwise, there really is no trick to have the form reload changes from a particular record, you have to reissue a query, however, not knowing forms too well, I cant offer more advice, I'm sorry. I will leave this for a Form guru.
iamlooperAuthor Commented:
They are PL/SQL procedures in a server side package. Even if I moved the procedures to the form I would still have the same issue I think. The table behind the form would still get updated, and the form would still need to be requeried.

Once the user presses the execute query button, there must be a way to intercept what the user entered into the form during the enter_query session. I seem to remember when I looked into this a while back (like a year ago), that you could iterate through the form objects looking for text the user entered? This wuold be the best solution for me if it is indeed possible.

Thanks mrjoltcola. Hopefully a form guru will pick this up and there's a 'OMG that's so simple' solution.
did you try the forms built-in GET_BLOCK_PROPERTY('BLOCK_NAME', LAST_QUERY) ?
iamlooperAuthor Commented:

That works beautifully!! So simple too. On the KEY_EXEQRY trigger I simply parse out the WHERE clause from the last_query text string.

That you SO MUCH jwahl !!!

  v_last_query      VARCHAR2(2048);
  v_where_start_pos NUMBER(4,0);
  v_order_start_pos NUMBER(4,0);
  v_where_clause    VARCHAR2(1024);
  v_last_query      := get_block_property('booking',last_query);
  v_where_start_pos := instr(v_last_query,'WHERE');
  IF v_where_start_pos = 0
    v_where_clause := null;
    v_where_start_pos := v_where_start_pos + 6;
    v_order_start_pos := instr(v_last_query,'order by');
    IF v_order_start_pos = 0
      v_where_clause := substr(v_last_query,v_where_start_pos);
      v_where_clause := substr(v_last_query,v_where_start_pos,v_order_start_pos - v_where_start_pos);
    END IF;
  where_clause.other_where_clause := v_where_clause;

Open in new window

iamlooperAuthor Commented:
I can't believe I've been stewing over this for a year! That will teach me to go to the exchange sooner. I thank you again !!!!
btw the last line of the code snippet is missing the block colon. Should be..
:where_clause.other_where_clause := v_where_clause;
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now