Die Verbindungsparameter für die Abfrage gegen eine MongoDB entsprechen den Verbindungsparametern für die Nutzung einer MongoDB als Verwaltungsdatenbank. An dieser Stelle wird keine Verbindungszeichenfolge in nativer MongoDB-Syntax verwendet, die das Format einer URL hat, sondern eine Verbindungszeichenfolge in der oben beschriebenen Syntax.

Der Aufbau des Abfragekommandos ist an eine SQL-SELECT-Syntax angelehnt:

SELECT {Eigenschaft 1} [AS {Alias 1}], …, {Eigenschaft n} [AS {Alias n}]
FROM {Collection}
[WHERE {Filterausdruck}]
[ORDERBY {Eigenschaft 1} [ASC|DESC], …, ORDERBY {Eigenschaft n} [ASC|DESC]]

Nur elementare Eigenschaften der MongoDB-Dokumente können ausgelesen werden. Bei Bedarf können dies aber auch elementare Eigenschaften sein, die in Unterobjekten (keinen Arrays) strukturiert sind. Dafür müssen die Unterobjekte namentlich in der folgenden Form angegeben werden: {Unterobjekt 1}. … .{Unterobjekt n}.{Eigenschaft}

Im Filterausdruck werden Vergleiche der Art {Eigenschaft}{Vergleichsoperator}{Wert} unterstützt. Mehrere dieser Ausdrücke können logisch UND/ODER-verknüpft werden. Eine Klammersetzung zur Festlegung der Auswertungsreihenfolge ist möglich. Der Filterausdruck wird bei dieser Datenquelle nicht direkt an diese weitergegeben, sondern muss vorab interpretiert und konvertiert werden. Dabei kommt der programminterne Makroparser zum Einsatz, sodass der Filter die Syntax eines gültigen Makroausdrucks haben muss. Das bedeutet insbesondere, dass der Eigenschaftsname in Form einer Variable mit vorangestelltem @ und der Vergleichswert in der Syntax einer Makrokonstante zu schreiben ist. Die Vergleichsoperatoren des Makrointerpreters sind zulässig, inklusive des Operators ~ für Wildcard-Vergleiche.

Ein Filterausdruck, der den aktuellen Textwert des Dokumentenfelds DocField gegen das Feld MongoField in einer MongoDB-Collection abfragt, kann z. B. wie folgt lauten:

@MongoField == "%DocField%"

Die Schreibweise @MongoField ist in diesem Fall keine typisierte Feldvariable. Der Makrointerpreter würde die Schreibweise MongoField nicht als syntaktisch korrekten Ausdruck verstehen. Bei Feldvariablen wird hier nur die Syntax für eine Textersetzung unterstützt, wie z. B. auch bei %DocField%.

Alternativ zur proprietären SELECT-Syntax sind Abfragen auch in nativer MongoDB-Syntax möglich. Der zu verwendende Ausdruck lautet, inklusive eines beispielhaften Filterausdrucks zur Auswahl von Dokumenten, deren Eigenschaft Property1 in einem bestimmten Wertebereich liegt, wie folgt:

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

Collection ist dabei ein Platzhalter für den konkreten Namen der abzufragenden Collection. Der Suchfilter ist in Form eines Dokuments in JSON-Syntax anzugeben. Für eine Suche über alle Dokumente muss ein leeres Dokument angegeben werden ({}). Innerhalb dieses JSON-Suchdokuments ist analog zur SELECT-Syntax die dynamische Platzierung von Feldwerten über den %Variablennamen% möglich.

Abweichend vom SELECT-Ausdruck werden bei dieser Suchvariante keine Namen der auszulesenden Eigenschaften definiert. Implizit werden alle elementaren Eigenschaften extrahiert, auch Eigenschaften in Unterobjekten. Arrays werden nicht extrahiert. Die Namen werden, per Punkt getrennt, aus den Namen der Unterobjekte und der Eigenschaft gebildet. Wenn nur bestimmte Eigenschaften gelesen werden sollen und das Auslesen in einer vorgegebenen Reihenfolge erfolgen soll, sollte die proprietäre SELECT-Abfrage verwendet werden. Das gilt z. B. für das Makro QueryDbRecord(), das die Zuordnung zu den Zielfeldern über die Reihenfolge der Felder im Quelldatensatz vornimmt.

MongoDB nutzt kein festes Datentypschema. Daher wird bei beiden Suchvarianten versucht, die Datentypen der ausgelesenen Eigenschaften aus den Werten des ersten gefundenen Dokuments zu ermitteln. Wenn aber einige Eigenschaften in diesem Dokument nicht vorhanden sind oder den Wert NULL haben, ist die Ermittlung des Datentyps nicht möglich. Als Folge kann dem Zielfeld einer gelesenen Eigenschaft auch in weiteren Dokumenten des Suchergebnisses kein typgerechter Leerwert zugewiesen werden (z. B. 0 für einen fehlenden Zahlenwert). Das Zielfeld erhält in diesem Fall ersatzweise einen leeren Wert des Standarddatentyps "Text", d.h. ein Leerstring. Nicht unterstützt werden außerdem innerhalb eines Abfrageergebnisses zwischen den Dokumenten abweichende Datentypen für die gleiche Eigenschaft. Ein einheitlicher Aufbau der Ergebnisdokumente wird somit vorausgesetzt. Wenn dies nicht der Fall ist, wird eine entsprechende Fehlermeldung angezeigt.

Die Nicht-Abfrage-Kommandos insertOne, updateOne, updateMany, replaceOne, deleteOne und deleteMany werden ebenfalls unterstützt, allerdings nur in nativer MongoDB-Syntax. Das folgende Beispiele stellt diese Kommandos dar. Die als Parameter übergebenen Dokumente sind dabei nur Beispiele. Nicht gesondert aufgeführt sind hier updateMany und deleteMany, da deren Parameter identisch zu denen von updateOne bzw. deleteOne sind.

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%"
})

Die Kommandos updateOne und replaceOne benötigen 2 Dokumente als Parameter. Das eine Dokument stellt den Suchfilter dar und das andere Dokument bestimmt die zu ändernden Eigenschaften bzw. den zu ersetzenden Dokumentinhalt.