You can bind the ProBindingSource to a query on a temp-table or database table using the following syntax:
Syntax
PUBLIC BindingSource ( INPUT query-hdl AS HANDLE
[ , INPUT include-fields AS CHARACTER,
INPUT except-fields AS CHARACTER] )
Where query-hdl is the query handle, include-fields is an optional, comma-separated list of fields from the data object to make available to the UI, and except-fields is a comma-separated list of fields from the data object to exclude from the UI. Note that you must supply the included and excluded field lists together whenever you use them.
Note: You must use the query handle to specify the query, even if the query is static.
You cannot simultaneously bind the same query to multiple ProBindingSources. A query can only be bound to a single ProBindingSource at any time. If you try to bind a query that is already bound to another ProBindingSource, the ProBindingSource throws an error.
Generally, you should open the ProBindingSource's query with the PRESELECT option, because the ProBindingSource needs the actual record count in the query at several points. Using this option optimizes getting the record count. If your application code does not specify this option for a dynamic query, the AVM applies the option. However, this behavior is less efficient than specifying the PRESELECT option yourself.
For large result sets, opening the query with the PRESELECT option might be time-consuming. In these cases, you might instead specify the MaxDataGuess property which provides the bound .NET controls with an approximate record count. The bound .NET control is immediately rendered based on the approximation and corrects itself when the actual record count is available.
You can use either a static or dynamic query for the ProBindingSource's data object. But, you must choose a scrolling query. If you use a static query, you must define it with the SCROLLING keyword. Dynamic queries are scrolling by default. Do not change the default behavior by setting FORWARD-ONLY to TRUE.
If you use a join query, you should qualify any ambiguous field names with the appropriate buffer name. Because queries can do self-joins, the qualifier must be the buffer name, rather than the table name. Using the buffer name also handles joins across databases. Your application must use an explicitly defined buffer for such joins. The buffer definition provides the database and table name for the ambiguous field.
For example, you have a buffer, bMgr, for the Employee table. You use that buffer in the following query, EMqry:
FOR EACH Employee, EACH bMgr WHERE Employee.Manager = bMgr.Name
If you wanted a ProBindingSource to make available the employee's name, his manager's name, and the manager's phone number, the signature is as follows:
PUBLIC BindingSource ( INPUT EMqry AS HANDLE,
INPUT "Employee.Name, Employee.Manager, bMgr.Phone" AS CHARACTER,
INPUT "" AS CHARACTER)
