ModelLoadOptions Class

Constructs an instance of ModelLoadOptions with the default options, which are to use Memory storage and to set LoadAsScriptBackedModel to be false.

Constructs an instance of ModelLoadOptions with the specified options.

Constructs an instance of ModelLoadOptions with the specified options.

Should the model be loaded so that objects are backed up by scripted representations? In this case objects in the UserDefined scope will have a source name and source position information.

When loading from a Dacpac or any other non-scripted source the model will not have source information. This means that when running static code analysis using the CodeAnalysisService some rules may not work correctly, and that existing objects in the model could not be replaced using the AddOrUpdateObjects(String, String, TSqlObjectOptions) method since there is no script with their original definition. For scenarios that use the CodeAnalysisService setting this to true is strongly recommended. Similarly if you wish to update existing objects in the model setting this to true may be useful.

Note that there is a potentially significant performance cost involved in creating a scripted model. All top level objects in the UserDefined scope will be scripted out as strings and then replaced with their scripted representations, after which the model will then have to fully resolve all relationships. This will cause a one-time performance hit at the time the model is loaded.

Should the model be stored in memory or should a file-backed storage be used?

Defines whether the model edit APIs throw a DacModelException if there are any blocking errors present in the model.

When adding a new object or deleting/modifying existing objects in the model using API calls such as AddObjects(String), AddOrUpdateObjects(String, String, TSqlObjectOptions), DeleteObjects(String) and ConvertToScriptedObject(TSqlObject, String), the model throws DacModelException signaling the presence of model blocking errors. Model blocking errors indicates the presence of serious errors such as parser, interpreter and other errors in the objects. Setting this option to false allows building the model even if it has such serious errors. Subsequently those objects with model errors can be retrieved using the GetModelErrors() method.

When objects with model blocking errors are added to the model, the object is edited such that errant parts are removed or commented out in a best effort manner to preserve the parts of the object that do not have errors. For instance a stored procedure that has a parser error in the procedure body will have its body commented out before adding to the model. As a worst case the object is completely dropped while preserving the model errors.

Note that current implementation handles objects with model errors as follows

1. Sql procedures and views are added to the model with commented body.
2. Other object types are completely dropped while preserving the model errors.