Using objects in the Event section
If you explicitly call the MDM
Document.Open method to open an MDM document, you must call the
Document.Close method to release the document. For more information, see
OnAfterMetaDataTransformation Event section.
Objects in the OnJobStart, OnNextCase, OnBadCase, and OnJobEnd Event sections
In the following sections, the Data Management Object Model (DMOM) registers some objects with the mrScriptBasic engine:
This means that the registered objects are automatically available in the script as intrinsic variables. However, DMOM requires an input metadata source to do this. This means that you cannot use these Event sections during a case data-only transfer or when are using a non-UNICOM Intelligence Data Model OLE DB provider to read the data.
The registered objects are:
Job
The Job object is of type IDataManagerJob, and is available as an intrinsic variable called dmghJob.
Although the Job object gives you access to the input and output metadata through the TransformedInputMetaData and TransformedOutputMetaData properties, these properties are designed to enable you to set up card, column, and punch definitions and other custom properties in the OnAfterMetaDataTransformation Event section. It is important that you do not make any changes to the structure of the input or output metadata in the OnJobStart, OnNextCase, OnBadCase, OnJobEnd, or OnAfterMetaDataTransformation Event sections. For example, you should not add or delete variables or categories or change a variable's data type.
If you have UNICOM Intelligence Reporter, the
Job.TableDocuments property returns a collection of TableDocument objects, one for each output data source that is written using a CDSC that is also read-enabled. A TableDocument object is not available for non-Data Model format output data sources or Quantum-format output data sources (because the Quantum CDSC is not read-enabled). Although you can define your tables in the OnJobStart, OnNextCase, OnBadCase, OnJobEnd, and OnAfterMetadataTransformation Event sections, you cannot populate or export your tables in these sections. (Attempting to do so might cause an error.) You should populate and export the tables in the OnAfterJobEnd Event section. For more information, see
Table scripting in a data management script.
GlobalVariables
The GlobalVariables object is of type IDataManagerGlobalVariables and is available in the script as an intrinsic variable called dmgrGlobal. This collection enables you to share objects between the OnAfterMetaDataTransformation, OnJobStart, OnNextCase, OnBadCase, and OnJobEnd Event sections. For example, you can add an object to this collection in the OnJobStart Event section and access the object in the OnNextCase, OnBadCase, and OnJobEnd Event sections.
Global SQL variables
If you define any global SQL variables in the GlobalSQLVariables section, each global SQL variable is available with the name defined for it in the GlobalSQLVariables section.
Questions
The IQuestions object is available in the script as an intrinsic variable called dmgrQuestions. The Questions collection contains a IQuestions object for each variable included in the SelectQuery statement in the InputDataSource section. In addition, each of these variables is available as a Question object with the name specified in the SelectQuery statement. For example, if the SelectQuery statement contains the following SELECT statement, the mrScriptBasic will automatically contain Question objects called Respondent.Serial, age, and gender.
SELECT Respondent.Serial, age, gender FROM vdata
Questions are only created after the OnBeforeJobStart event and include content from the metadata section.
Log
The Log object is available as an intrinsic variable called dmgrLog. If your DMS file does not have a Logging section, no logging will be performed.
WeightEngines
The WeightEngines object is available as an intrinsic variable called dmgrWeightEngines and returns a collection of WeightEngine objects, one for each output data source. The WeightEngine objects are automatically initialized and so you do not need to call the WeightEngine.Initialize method. In fact calling this method is likely to lead to an error.
Objects in other object models can be accessed using the CreateObject function.
See