If bdo_autoapply is set, applyupdates is called automatically after post
Source position: msebufdataset.pas line 688
type bufdatasetoptionty = ( |
||
bdo_postsavepoint, |
||
bdo_deletesavepoint, |
||
bdo_cancelupdateonerror, |
|
If applying a record's update fails, bdo_cancelupdateonerror reverts that single record's modification |
bdo_cancelupdatesonerror, |
||
bdo_cancelupdateondeleteerror, |
||
bdo_editonapplyerror, |
||
bdo_restoreupdateonsavepointrollback, |
||
bdo_rollbackonupdateerror, |
||
bdo_noapply, |
||
bdo_autoapply, |
||
bdo_autoapplyexceptions, |
||
bdo_autocommitret, |
||
bdo_autocommit, |
||
bdo_refreshafterapply, |
|
Set bdo_refreshafterapply to refresh this query (only) after applyupdates |
bdo_recnoapplyrefresh, |
||
bdo_refreshtransaction, |
|
By default, refresh |
bdo_notransactionrefresh, |
||
bdo_recnotransactionrefresh, |
||
bdo_checkbrowsemodebylookupchange, |
||
bdo_noprepare, |
||
bdo_cacheblobs, |
|
Some backends (e.g. Postgres) do not support fetching a blob field's value lazily on demand |
bdo_offline, |
|
bdo_offline disconnects from the database right after the initial fetch |
bdo_local |
|
bdo_local mode is meant for offline editing of a small dataset fetched from an SQL database, with modifications logged to disk and applied/committed to the server later (comparable to TClientDataset) |
); |
If bdo_autoapply is set, applyupdates is called automatically after post. If bdo_autocommitret is also set, the transaction's commitretaining is called after applyupdates; this works well with Firebird (data cursors stay valid after commitretaining) but is more problematic with Postgres, which has no real commitretaining equivalent. bdo_autocommit does a plain commit instead, leaving no open write transaction after applyupdates — only one of bdo_autocommitret/bdo_autocommit can be set at a time.