Delta Mechanism
Write-Optimized DataStore does not support the image based delta, it supports request level delta, and you will get brand new delta request for each data load.
Since write-optimized DataStore objects do not have a change log, the system does not create delta (in the sense of a before image and an after image). When you update data into the connected InfoProviders, the system only updates the requests that have not yet been posted.
Write-Optimized Data Store supports request level delta. In order to capture before and after image delta, you must have to post latest request into further targets like Standard DataStore or Infocubes.
Archiving not possible
Using the data archiving process, you can archive and store transaction data from InfoCubes and DataStore objects. This function is NOT available for write-optimized DataStore objects.
The data archiving process consists of three main steps:
1. Creating the archive file/near-line object
2. Storing the archive file in an archiving object (ADK-based) or near-line storage
3. Deleting the archived data from the database
A data archiving process is always assigned to one specific InfoProvider and has the same name as this InfoProvider. It can be created retrospectively for an existing InfoProvider that is already filled with data.
In ADK archiving, an archiving object is created for each InfoProvider.
As with the role of the archiving object during ADK archiving, the near-line object addresses the connected near-line storage solution during near-line storage. It is also generated from the data archiving process for an InfoProvider. Near-line objects consist of various near-line segments that reflect different views of the respective InfoProviders and can also reflect the different versions of an InfoProvider.