Note that the model is completely updated in one call to a stored procedure. SQL server table parameters are widely used for data transfer.

Models are updated as follows.

First, the client sends the entire model to the server.

The system finds the model name for the corresponding action and calls the stored procedure with the .Metadata suffix. This procedure returns multiple sets with empty content. The field names in these sets define the rules for how to convert the contents of the model received from the client to the parameters of the stored model update procedure.

The system converts the obtained raw data into a set of tables using the received metadata.

The procedure with the .Update suffix is called and the converted tables are passed to it.

Rules for interpreting .Metadata sets

The name of the first field of each set always consists of three items separated by a '!' character.

• The first item is the name of the parameter in the .Update procedure.
• The second item is the path to the data from the data model. Although some values may be arrays, the path is still specified through a point.
• The third item is always the value of Metadata.

The remaining fields of the set are properties in the model and, accordingly, the fields in the tabular variable.

The number of tabular parameters in the .Update procedure (excluding predefined ones) will always be equal to the number of sets returned by the .Metadata procedure.

Example

Consider the procedure for updating a document. A working example of tables and stored procedures can be found on GitHub

Let's define tabular types

The first type will correspond to the a2v10sample.Documents table, and the second to the a2v10sample.DocDetails.

The procedure for obtaining metadata will be as follows:

It returns two sets. The first set describes the document itself (there will always be one record in the table) with all the required fields. This table will be passed to a parameter named @Document. Note that in the name [Document!Document!Metadata], the first word Document is the name of the parameter, and the second Document - is the path in the model where you want to receive the data from.

The second set describes the row table. This table will have as many rows as the Document.Rows array of the original model. The parameter name is @Rows.

The update procedure will be as follows:

The procedure simply updates (or inserts) the document and its rows using the merge statement. Note that a pseudo-table inserted is used to obtain the document ID (which is needed to insert rows)

Additional service fields in record sets

When filling in data tables from models, the following service fields are added to the tables. If they are declared in tabular types, their values will be filled in. These fields are used to bind child records (because they may be new and their identifiers may not yet exist).

Name	Type	Description
GUID	uniqueidentifier	Unique value. Used in conjunction with ParentGUID.
RowNumber	int	The row number in the table (starting with 1).
CurrentKey	Various types	The current key in Map type tables. Used in conjunction with the ParentKey field of a child table.
ParentId	Various types	arent record ID. An identifier is always a property named Id.
ParentGUID	uniqueidentifier	Unique identifier of the parent record (property named GUID from the parent table).
ParentKey	Various types	Parent record key (CurrentKey). Used to populate tables of type Map.
ParentRowNumber	int	The row number of the parent record (a property named RowNumber from the parent table).

Tip

To see what data comes into the stored procedure, you can use the following code snippet (where @Rows is the name of the table parameter):