The connection parameters for querying against a MongoDB are modeled on the connection parameters for using a MongoDB as a management database. At this point, instead of using a connection string in native MongoDB syntax that has the format of a URL, use a connection string in the syntax described above.

The structure of the query command is based on that of query commands in SQL-SELECT syntax:

SELECT {property 1} [AS {alias 1}], …, {property n} [AS {alias n}]
FROM {collection}
[WHERE {filter expression}]
[ORDERBY {property 1} [ASC|DESC], …, ORDERBY {property n} [ASC|DESC]]

Only elementary properties of MongoDB documents might be read, but if needed, these might also be elementary properties structured as subobjects (not arrays). For this, specify the subobjects by name in the following form: {subobject 1}. ... .{subobject n}.{property}

In the filter expression, comparisons of the type {property}{comparison operator}{value} are supported. You can logically link many of these expressions with AND/OR. You can also set the brackets to determine the order of evaluation. The filter expression is not sent directly to this data source; instead, it must be interpreted and converted in advance. The program's internal macro parser is used here, so the filter must have the syntax of a valid macro expression. In particular, this means that the property name must be written as a variable preceded by @, and the comparison value must be written in the syntax of a macro constant. The macro interpreter's comparison operators, including the ~ operator for wildcard comparisons, are permitted.

A filter expression that queries the current text value of the document field DocField against the MongoField field in a MongoDB collection might be written as in the following example:

@MongoField == "%DocField%"

The @MongoField notation is not a typed field variable in this case. The macro interpreter would not understand the notation MongoField as an expression that is syntactically correct. In the case of field variables, only the syntax for text replacement is supported here, as is the case with %DocField%, for example.

As an alternative to the proprietary SELECT syntax, queries can also be made in native MongoDB syntax. Following is the expression to be used, including an example filter expression for selecting documents whose Property1 property lies within a certain value range:

Db.Collection.find({
   Property1: {
      $gte: 1000,
      $lte: 2000
   }
})

Collection is a placeholder for the specific name of the collection to be queried. Soecufy the search filter in the form of a document in JSON syntax. For a search across all documents, specify an empty document ({}). Within this JSON search document, the dynamic placement of field values is possible via the %VariableName%, analogous to SELECT syntax.

In contrast to the SELECT expression, no names of the properties to be extracted are defined in this search variant. Implicitly, all elementary properties are extracted, including properties in sub-objects. Arrays are not extracted. The names are formed from the names of the sub-objects and the property, separated by a dot. If only certain properties are to be read and the readout is to take place in a predefined sequence, the proprietary SELECT query should be used. This applies, for example, to the QueryDbRecord() macro, which makes the assignment to the target fields via the order of the fields in the source data record.

MongoDB does not use a fixed data type schema. Therefore, both search variants attempt to determine the data types of the read properties from the values of the first document found. However, if some properties are not present in this document or have the value NULL, it is not possible to determine the data type. As a result, the target field of a read property cannot be assigned a type-appropriate blank value in other documents of the search result (e.g., 0 for a missing numerical value). In this case, the target field will receive an empty value of the standard data type "Text" instead (i.e., an empty string). Different data types for the same property are also not supported within a query result between the documents. A uniform structure of the result documents is therefore assumed. If this is not the case, a corresponding error message will be displayed.

Also supported are the non-query commands insertOne, updateOne, updateMany, replaceOne, deleteOne, and deleteMany; however, they are only supported in native MongoDB syntax. The following examples illustrate these commands. The documents transferred as parameters are only examples. Not listed separately here are updateMany and deleteMany, as their parameters are identical to those of updateOne and deleteOne.

db.Collection.insertOne({
   Property1: "%Field1%",
   Property2: "%Field2%",
})

db.Collection.updateOne({
   Property1: "%Field1%"
},{
   $set: {
      Property2: "%Field2%"
   }
})

db.Collection.replaceOne({
   Property1: "%Field1%"
},{
   Property1: "%Field1%",
   Property2: "%Field2%",
})

db.Collection.DeleteOne({
   Property1: "%Field1%"
})

The updateOne and replaceOne commands require two documents as parameters. One document represents the search filter and the other document determines the properties to be changed or the document content to be replaced.