I use TSMARTQuery that cannot successfully obtain editable query results, but it can be used when using ToraQuery. Why is this? You must understand that in order to make any data set components can be edited, you must ensure that the records in the data table are allowed to be updated and can be independently identified. For TSMARTQuery, it must indicate the field name in the property keyfields to identify records (for example, fields, primary keys, or unique indexes). There is a way to choose - if one of the query fields is a new table, RowID, TsmartQuery will find it and use RowID to identify it when the property Keyfields is empty. Properties UpdatingTable service display table will be updated (there are many tables in the query). If its value is empty, the table that is being used will display the result of the SQL operation. In order to better operate the results of the query, it should always be set to set the properties UpdatingTable. When do not connect to the database, how do I use TDBGRID to display data, program form? You can use the TVirtualTable component. If the data structure is known, you can use a field editor to create a field when designing. If the data structure is determined by the application, you must use the AddField method. Applications can populate TvirtualTable as the data to ordinary table. You can see this location:
... /odac/demos/virtualTable/VTable.dpr
Starting from the 1.80 version, when the SQL operation is executed, if the database record is changed or changed, the ODAC-ToraQuery starts to display an error ("Update Failed"), but there is no such error in ODAC. . I automatically remove this error? This feature is added after the 1.80 version of ODAC is to simplify the transaction processing from BDE to ODAC in the project. BDE's tupdateSQL supports this method. In order not to appear this error message, the value of the attribute strictupdate must be set to false. I am very sorry, this is a public property, that is, its value can be modified at runtime. Using ODAC creates an application, users can edit records directly in DBGRID. How can I prohibit the user's deletion record? If you use ToraQuery like TDataSet, you can do very simply disable the recorded deletion, insert, and update operations. Simply cleared the related properties (SQLDELETE, SQLINSERT, SQLUPDATE). This method does not apply to SQL operation or PL-SQL block. If the delete operation is disabled, the reason may be executed in the DBGRID, because this component cannot be "guess", so that the deletion is prohibited.
The user must be delete, insert, and edit records in DBGRID, but the deletion operation is not implemented in DB. If you do not populate SQLDelete in ToraQuery, you will not allow deletion operations in DBGRID. Is there a way to cross this limit? The method is very simple, enter the following in Sqldelete:
Begin
NULL;
END;
The same method can be used to allow recording updates and inserts, and this method cannot update the actual data sheet. If you do not need to implement any update operations in the data table, you can use localupdates. The primary key of the data table is populated with the sequence. Whether the meaning of this key can be prohibited in the client application without any additional queries? If you use Oracle7, get the unique way to get the new key value is an explicit query. Replacing this field with a database trigger can completely solve this problem. To simplify network transmission and output time, you can use the following SQLInsert PL-SQL block instead of SQL operation: Begin
Select
INSERT INTO
END;
If you use Oracle8, you can use the database trigger to replace the original field. We use trigger update field values to complete update SQL operations:
INSERT INTO
In this way, it can be used to use SQL operation in Oracle8 to set it:
INSERT INTO
All of the methods above, examples are assumed, the
Do not indicate the fields that can be updated by the trigger in the property KeyFields. Always indicate refreshmode. If the field can be updated with a trigger, refreshmode should be RMAFTERUPDATE or RMALWAYS. If it is insert, it is RMAFTERUPDATE or RMALWAYS. If it is inserted and updated, only - Rmalway is TsmartQuery for ODAC 1.80 version The conversion adding mechanism is the most common situation. User stored procedures for data updates. In addition to inputting parameters, or output parameters, for example, "state". How do I handle output parameters? Please see the example below:
For example, the content of the attribute SQL is as follows:
Select * from
Write
SELECT 0 as State, T. * from
Naturally, these fields are invisible to application users. We wrote a process call attribute SQLInsert, SQLUPDATE AND SQLDELETE, for example:
Begin
END;
We set up the property returnparams for TRUE
