| ORDER bye clause [message #136898] |
Mon, 12 September 2005 03:38  |
nostalgia
Messages: 8
Registered: March 2005
Location: jordan
|
Junior Member |
|
|
how can i order a tabuler data base block using a non-data base item in the order by clause ???
ex.
i have
student_no , student_name as data base items in block STD
then i added a non-data-base item student_ID in the same block STD
i get the data of student_id in post change of student_no ??
i want to order the block STD by student_id
[Updated on: Mon, 12 September 2005 03:41] Report message to a moderator |
|
|
|
|
|
|
|
| Re: ORDER bye clause [message #139668 is a reply to message #139664] |
Thu, 29 September 2005 02:09  |
 |
djmartin
Messages: 10181
Registered: March 2005
Location: Surges Bay TAS Australia
|
Senior Member
Account Moderator |
|
|
From the reference manual:| Quote: |
Post-Change Trigger
Description
Fires when any of the following conditions exist:
. The Validate the Item process determines that an item is marked as Changed and is not NULL.
. An operator returns a value into an item by making a selection from a list of values, and the item is not NULL.
. Form Builder fetches a non-NULL value into an item. In this case, the When-Validate-Item trigger does not fire. If you want to circumvent this situation and effectively get rid of the Post-Change trigger, you must include a Post-Query trigger in addition to your When-Validate-Item trigger. See "Usage Notes" below.
Definition Level - form, block, or item
Legal Commands
SELECT statements, unrestricted built-ins
Enter Query Mode - no
Usage Notes
. The Post-Change trigger is included only for compatibility with previous versions of Form Builder. Its use is not recommended in new applications.
. The Post-Query trigger does not have the restrictions of the Post-Change trigger. You can use Post-Query to make changes to the fetched database values. Given such changes, Form Builder marks the corresponding items and records as changed.
On Failure
If fired as part of validation initiated by navigation, navigation fails, and the focus remains in the original item.
If there are V2-style triggers in the form and Form Builder is populating a record with fetched values, the following restrictions apply:
. Form Builder ignores any attempt to change the value of a database item in the record.
. Form Builder does not execute any SELECT statement that only affects database items in the record.
. Form Builder does not execute a SELECT statement that does not have an INTO clause.
. If Form Builder does not execute a SELECT statement in a V2-style trigger step, it treats the trigger step as though the step succeeded, even when the Reverse Return Code trigger step property is set. During fetch processing, Post-Change triggers defined as PL/SQL triggers do not operate with these restrictions. Regardless of trigger style, during a record fetch, Form Builder does not perform validation checks, but marks the record and its items as Valid, after firing the Post-Change trigger for each item.
Fires In
Validate the Item
Fetch Records
Review Process Flowcharts
Post-Change Trigger restrictions
Note that it is possible to write a Post-Change trigger that changes the value of an item that Form Builder is validating. If validation succeeds, Form Builder marks the changed item as Valid and does not revalidate it. While this behavior is necessary to avoid validation loops, it does allow you to commit an invalid value to the database.
|
David
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
