V3.0 finally comes with optional write-back to external data source features. CRUD (Create, Update, Delete) is fully supported for the external data source, if SharePoint list items are created, updated or deleted. In this way any SharePoint list, e.g. contacts, tasks, events, KPI-lists could be used as "front-end" to LOB data, e.g. databases, Office data, CRM and ERP systems.
System requirements for full write-back
- The data connectivity provider selected in the BDLC settings must support write-back. Most .NET native providers and e.g. OLEDB do generally support write-back in case of databases as backend, e.g. SQL Server, MS Access, Oracle etc.
Write-back to text files, Excel files is mostly not supported by these drivers.
- The user account used to connect to data source must have write access to the external data source. Please check connection strings for write options.
- The external data source (e.g. database table) should be updatable. Most database tables and simple views (with one table) are updatable, if primary keys are available. Views, that contain more then one table and tables without primary keys are not updatable.
How to disable write-back?
Write-back is disabled by default. You have to explicit enable this feature in the list BDLC settings.
When write-back operations are fired, if enabled?
Write backs are implemented to take place immediately after changes in the Sharepoint list are made, e.g. updates, deletes or inserts of items.
What about errors with write-back operations?
Errors with write-back operations (e.g. insert / update / delete errors) are shown as typical SharePoint errors with full error message. Changes in the list item, that cause this error are rolled back (no changes).
What about triggers, calculated fields on data source side?
Triggers, calculated fields and other data source related operations can modify the data record after write-back. You will not see such changes in the SharePoint list immediatly. These modifications are available after next list update (manually using the actions menu or using the background update service).
What about using the SharePoint list form as a data entry form, to add records to the external data source?
If write-back is supported and you set valid primary keys manually, it will work as expected. It will not work with auto-incemented, time-stamp orGUID-based primary keys on data source side and calculated fields on SharePoint side..
What about using the data grid view of a SharePoint list to edit?
If write-back is generally supported, it will work with the data grid too. You don't get any detailed error messages in this case.