In a multi-level insert, multiple mobile business objects are synchronized in a single operation. The mobile business objects must have a defined relationship, and the insert parameters must support the relationship.
Some business processes require multiple related enterprise information system (EIS) operations; for example, creating a sales order with line items. The parent/child relationship is often represented by primary key(PK) / foreign key(FK) attributes in the parent and child mobile business objects (MBOs). When you construct these types of MBOs in an offline client application, the primary-key and foreign-key values are transitory. When EIS operations are called to create real data, the EIS systems generate the actual key values, and the primary key of the parent is copied to the related child MBO creation operations. These types of operations are known as "chained insert" or "multilevel insert."
For database MBOs using Sybase databases, dragging and dropping a table that contains autoincrement columns (one mechanism for generating primary keys) automatically creates the appropriate operations for obtaining the parent's generated keys and applying them to the children.
Synchronization of the child MBO should occur either independently or through the parent MBO. See the Developer Guide: <Device Platform> Object API Applications documentation for details.
The insert operation for the parent MBO must return a single row that contains the primary-key values. The column labels must match the attribute names of the parent MBO.
CREATE TABLE parent(pk int autoincrement primary key, p1 varchar(30),...) CREATE TABLE child(fk int references parent.pk, ...)
INSERT INTO parent(p1, ...) VALUES(?, ...); SELECT @@IDENTITY AS id;
This batch query inserts the new parent row, and returns the newly generated primary key value.
You must understand the key-generation mechanism used by the EIS application from which you are developing, and be able to determine how to retrieve the newly generated keys during the insert operation (frequently, this logic is wrapped in a stored procedure).
This same technique applies to Web service, SAP, and other EIS systems, though the insert-operation definitions differ.
The single row that is returned must contain the column referenced in the relationship between the parent MBO and the child MBO, and the label of the column must match the from attribute name of the parent MBO.
Not all columns in the inserted row are required. For example, not all columns are selected or required for a drag-and-drop database operation.
If the child has multiple foreign-key attributes pointing to the parent, the relationship should list all relevant parent-to-child attributes. As long as the row returned from the parent insert contains all those columns, the child insert should work; all the foreign-key fields are populated from the parent insert result set.