Posting Data
Go Up to Modifying Data
After you finish editing a record, you must call the Post method to write out your changes. The Post method behaves differently, depending on the dataset's state and on whether you are caching updates.
- If you are not caching updates, and the dataset is in the dsEdit or dsInsert state, Post writes the current record to the database and returns the dataset to the dsBrowse state.
- If you are caching updates, and the dataset is in the dsEdit or dsInsert state, Post writes the current record to an internal cache and returns the dataset to the dsBrowse state. The edits are not written to the database until you call ApplyUpdates.
- If the dataset is in the dsSetKey state, Post returns the dataset to the dsBrowse state.
Regardless of the initial state of the dataset, Post generates BeforePost and AfterPost events, before and after writing the current changes. You can use these events to update the user interface, or prevent the dataset from posting changes by calling the Abort procedure. If the call to Post fails, the dataset receives an OnPostError event, where you can inform the user of the problem or attempt to correct it.
Posting can be done explicitly, or implicitly as part of another procedure. When an application moves off the current record, Post is called implicitly. Calls to the First, Next, Prior, and Last methods perform a Post if the table is in dsEdit or dsInsert modes. The Append and Insert methods also implicitly post any pending data.
Warning: The Close method does not call Post implicitly. Use the Data.DB.TDataSet.BeforeClose event to post any pending edits explicitly.