Home » Developer & Programmer » Forms » execute_query failure
 execute_query failure [message #124957] |
Wed, 22 June 2005 09:07  |
Lee Sutton
Messages: 20
Registered: June 2005
Location: Sheffield
|
Junior Member |
|
|
Hello,
I am creating 2 'events'. The key here is that I am querying data from a table using a default_where clause in the pre-query trigger on the block.
For the first event, 9 rows are returned (as required) and the event can be processed. However, 0 rows are returned when processing the second event. I have trapped the value of the default_where clause and they are identical.
For further proof, I debugged the post-query trigger. A key variable was set when creating event 1, but is still null for event 2.
Therefore, I can only presume the execute_query procedure (itself) has failed. Has anyone seen this happen before? Can anything be done about it?
Note: If I exit the application and then re-enter to create the second event I have no problems.
Thankyou for your time.
Regards
Lee Sutton
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: execute_query failure [message #125226 is a reply to message #125133] |
Thu, 23 June 2005 20:20  |
 |
djmartin
Messages: 10181
Registered: March 2005
Location: Surges Bay TAS Australia
|
Senior Member
Account Moderator |
|
|
You don't need quotes around your date fields unless they are in character format and then I would recommend that you MANUALLY convert them to DATE type with a TO_DATE and NOT let the system do it for you automatically as you MAY have a difference in NSL_DATE_FORMAT, etc, between your AS and DB, especially between development, test, and production.
Upd: I assume that EFFECTIVE_FROM and EFFECTIVE_TO are of type 'DATE' ... yes?
David
Update: You are using double-click to get out of the field, maybe there is validation pending ... try putting an 'ENTER' command at the beginning of your double-click procedure.
PS For readability I would normally put the two where clauses as local variables. This makes the 'if' test a bit easier to read.
[Updated on: Fri, 24 June 2005 00:38] Report message to a moderator |
|
|
|
|
|
| Re: execute_query failure [message #125243 is a reply to message #125242] |
Fri, 24 June 2005 00:26 |
|
djmartin
Messages: 10181
Registered: March 2005
Location: Surges Bay TAS Australia
|
Senior Member
Account Moderator |
|
|
Short answer: yes
Long answer: Let's say you have one block in your form and it is a 'data' block.
You write code, for example, in the When-New-Form-Instance trigger, you do an 'enter-query' command, then put a value in some of the fields, and then do the 'execute-query'. Assuming that there is nothing in the 'Default Where' of the block, you will retrieve those records selected by the data in the field as per Query-by-example. This will happen every time you run the form.
Often we present the user with just the 'data' block and get then to press the 'enter-query' button, place data into fields, and then get them to press 'execute-query'. Again they get data retrieved.
Unfortunately, most users can not handle this 'dual' nature of screen fields. One mode for data entry, and one for data retrieval. I usually do something obvious like change the colour of the menu bar, or have a label that says 'Enter mode' or 'Query mode' to act as a visual hint.
But more often they want the screen 'idiot-proofed' and we have a 'control' block with fields at the top of the screen into which they add data and then we define those fields as part of the 'data' block's 'default where' property.
But now we want to do something more complicated and we have to join our 'data' table to different tables depending on whether a particular 'search' field has been populated. This is where we must redefine the 'default where' for the 'data' block before we can run the query.
So we put data in the 'control' fields, press a button which does go_block('data');
redefine_where_clause;
execute_query
Hope this helps.
David
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Fri May 02 05:24:51 CDT 2025
|
] 
Blog
Search
Help
Members
Register
Login
Home
