Because of the standard interaction between bound UI controls and the ProBindingSource, the ProBindingSource can perform basic update tasks automatically. The ProBindingSource can create and delete records in response to appropriate user actions. This capability might be useful during the rapid prototyping stage of your development.
You control this behavior with the AutoUpdate property. Note that using this automatic behavior has undesirable limitations that make it inappropriate for most business applications. Because of these limitations, Progress Software Corporation recommends that you not use this behavior outside a rapid prototyping environment. In accord with this recommendation, the AutoUpdate property defaults to FALSE.
Before deciding to use automatic updates outside a rapid prototyping environment, consider the following limitations carefully:
The ProBindingSource can only update the buffer from the screen values after all validation opportunities have passed and the transaction is complete from the UI control's perspective.
To maintain separation between UI and business logic, a business application should perform data validation on the buffer fields, rather than on the screen values. Using this approach, the application probably moves the screen values into the buffer itself, either directly or with the ProBindingSource's Assign( ) method, then does the validation before the ProBindingSource updates the buffer automatically. This technique eliminates the utility of this part of the automatic behavior.
A business application must handle any errors that occur while updating the database or temp-table. Because the UI control considers the transaction complete before the ProBindingSource makes its updates, the application could not effectively tell the UI control about errors encountered during creates, assigns, and deletes. The UI control would not behave appropriately when errors occur.
A business application commonly has initial values that must be set programmatically during a create operation. The ProBindingSource's automatic behavior does not include setting these values. Therefore, the application needs to set these values itself, reducing the utility of the automatic behavior.
A business application often needs to make changes to related data during an update or delete operation. In case the changes are canceled, the application needs all the changes scoped to a single, larger transaction. The ProBindingSource's automatic behavior cannot accommodate this requirement.
The ProBindingSource might have a join query as its data source object. In this case, the ProBindingSource does not know which records in the joined tables need to be created or deleted. For example, consider a query that joins the Customer and Salesrep tables to provide the UI control with each customer's sales region. If a user deletes a Customer record, the application should not also delete the Salesrep record.
The CreateRow and CancelCreateRow events override the AutoUpdate behavior. If you subscribe to these events, your application does not check the value of AutoUpdate when it creates or cancels a new row.
The ProBindingSource can only update the buffer from the screen values after all validation opportunities have passed and the transaction is complete from the UI control's perspective.