Kompatibilitätseinstellungen – oder Fahren mit angezogener Handbremse (Teil 1)

Bei Code-Kitchens verbringe ich in der Regel einige Zeit mit den Datenbankeinstellungen, insbesondere mit den Kompatibilitätseinstellungen. Oft entsprechen bestimmte Einstellungen nicht den Best Practices, und in Gesprächen mit dem Anwendungsentwickler höre ich : „Oh, die habe ich nie geändert“ oder „Ich bin mir über die Auswirkungen nicht sicher, also lasse ich sie lieber weg“.

Da sie sich drastisch auf die Leistung oder das Verhalten Ihrer Anwendungen auswirken können, haben wir eine Reihe von Blogbeiträgen begonnen, um einige dieser „geheimen“ Einstellungen zu erörtern.

Teil 1 der Kompatibilitätseinstellungen – QUERY BY FORMULA

Diese Einstellungen zwingen 4D dazu, sich wie in der Version 2004 zu verhalten, was den Funktionsumfang und die Leistung reduziert. Dabei ist es so einfach, sie zu ändern, aber die Kunden haben Angst vor unbekannten Nebenwirkungen.

QUERY BY FORMULA war in v2004 recht langsam (weil alle Datensätze an den Client übertragen wurden), ohne großen Mehrwert. Daher wurde sie von den meisten Entwicklern ignoriert. Die Regeln wurden mit v11 geändert.

Der QBF-Befehl (um es in diesem Blogbeitrag kurz zu halten) ermöglicht es Ihnen, Berechnungen wie die Suche nach Bildgröße oder Textlänge zu verwenden. Die Vorteile dieser Funktion sind ziemlich offensichtlich. Allerdings können solche Berechnungen keinen Index verwenden und sind daher langsamer als eine indizierte Abfrage.

Aber der QBF-Befehl kann noch viel mehr! Er kann Abfragegruppen mit Klammern kombinieren: ((Feld1=1) und (Feld2=“A“)) OR ((feld1=50) und (feld2=“B“)).

Wenn Sie den QBF-Befehl nicht verwenden, müssen Sie zwei Abfragen ausführen und Sets verwenden, was zu einem wesentlich höheren Netzwerkverkehr, einer größeren Abhängigkeit von der Netzwerkleistung und einer höheren Belastung des 4D Servers führt. Der Abfrageoptimierer von 4D Server erkennt automatisch den besten (schnellsten) Weg, um solche Bedingungen für Felder derselben Tabelle – oder sogar verwandter Tabellen – zu behandeln.

Und das Beste ist, dass er selbständig Relationen (auch Joins genannt) erstellen kann, auch wenn im Strukturmodus keine Verknüpfung gezeichnet wird. Ja, Sie können Beziehungen dynamisch aufbauen, um Abfragen durchzuführen (wenn die Option „QUERY BY FORMULA Uses SQL Joins“ aktiviert ist).

Die Option „QUERY BY FORMULA Uses SQL Joins“ könnte verwirrend sein, weil sie überhaupt nichts mit SQL zu tun hat, man sollte sie eher als „QBF unterstützt dynamische Beziehungen“ betrachten.

Lassen Sie uns eine einfache Struktur als Beispiel verwenden:

Sowohl QUERY und QUERY BY FORMULA konnten für die Suche über eine Relation verwendet werden, z.B:

QUERY BY FORMULA([Table_2];[Table_1]Field_2="1")

Aber nur QBF erlaubt es Ihnen, die Beziehung explizit zu definieren (was die Verwendung jeder möglichen Beziehung erlaubt), anstatt zu verlangen, dass eine definierte Beziehung bereits existiert. Stellen wir uns nun vor, dass es eine zweite logische Verbindung zwischen diesen beiden Tabellen gibt, die aber noch nicht als 4D-Beziehung existiert … Feld3 mit Feld2. QBY erlaubt es Ihnen, die Beziehung spontan zu definieren:

QUERY BY FORMULA([Table_2]; ([Table_1]ID=$var)& \
([Table_1]Field_2=[Table_2]Field_3))

Hinweis: Bei der Verwendung von dynamischen Verknüpfungen müssen zwei Felder aus verschiedenen Tabellen miteinander verglichen werden. Wenn dies Teil einer Abfrage ist, wird dies automatisch als Verknüpfung behandelt, um eine Beziehung zu definieren.

Wenn Sie nach einem Wert in einer anderen Tabelle suchen wollen, müssen Sie ihn zunächst einer lokalen Variablen zuweisen. Damit ist klar definiert, dass Sie ihn als Konstante verwenden wollen.

Das Aktivieren der Option „QUERY BY FORMULA Uses SQL Joins“ ist zwingend erforderlich, damit der „neue“ Abfrage-Editor(d.h. der mit v14 eingeführte Abfrage-Editor) Relationen verwenden kann. Der Grund ist einfach, er verwendet den QUERY BY FORMULA Befehl intern.

Zusammenfassung:

• QUERY BY FORMULA erlaubt die Verwendung von Klammern, um komplexe Abfragebedingungen auszudrücken, während QUERY nur mehrere ODER- oder mehrere UND-Bedingungen zulässt, nicht aber eine Kombination aus beiden.
• QUERY BY FORMULA unterstützt Joins und dynamische Abfragen.
• QUERY BY FORMULA erlaubt die Verwendung von Formeln, z. B. für die Bildgröße.
• QUERY BY FORMULA wird auf dem Server ausgeführt (ähnlich wie eine normale QUERY) und bietet die gleiche oder sogar eine bessere Geschwindigkeit, da sie weniger Netzwerkverkehr erzeugt als eine Kombination aus QUERY und Mengenoperationen.

Beachten Sie, dass alles oben Gesagte für die klassische 4D-Sprache gilt. ORDA-basierterCode wird immer auf dem Server ausgeführt.

Erforderliche Migrationsarbeit zur Aktivierung der Kompatibilität

Die obigen Einstellungen sind nur im Kompatibilitätsdialog für Strukturen sichtbar, die mit 4D v2004 oder älter erstellt wurden. Wenn Sie diese Einstellungen nicht sehen, ist Ihre Struktur neueren Datums und verhält sich immer im v11-Modus, Sie sind also startklar!

Verwenden Sie die Option Suchen im Entwurfsmodus, um zu suchen nach QUERY BY FORMULA. Da sich Ihre Struktur im „langsamen“ v2004-Modus befindet, sollte die Liste kurz sein. Doppelklicken Sie auf jedes Ergebnis und überprüfen Sie den Code.

Solange die Formel Konstanten verwendet, wie z.B.:

QUERY BY FORMULA([Table_2];[Table_1]Field_2="1")

Oder

QUERY BY FORMULA([Table_2];[Table_1]Field_2=$var) // similar for var or <>var

Alles ist gut, es gibt nichts zu tun. 4D Remote interpretiert die Variable und sendet ihren Inhalt an den Server (ähnlich wie bei einer Konstanten). Der Wert des Clients wird immer verwendet, auch wenn die Abfrage vom Server ausgeführt wird.

Wenn die Formel eine Methode ist, wie z.B.:

QUERY BY FORMULA([Table_2];RunQuery)

Sie müssen den Inhalt der Methode öffnen und überprüfen. Wenn der Methode Parameter übergeben werden, ist die Wahrscheinlichkeit groß, dass es sich um eine generische Methode handelt (aber Sie sollten es trotzdem überprüfen). Wenn keine Parameter übergeben werden, ist die Wahrscheinlichkeit groß, dass die Methode fehlschlägt.

Stellen Sie sich vor, RunQuery enthält:

$0:= ([Table_2]=myvar)

Der Inhalt von myvar ist auf 4D Remote und 4D Server unterschiedlich, so dass die Ausführung dieser Methode auf 4D Server fehlschlagen wird. Sie wird andere Ergebnisse liefern.

Es gibt zwei Möglichkeiten, dieses Problem zu beheben. Bei einfachen Abfragen wie oben können Sie die Methode einfach in RunQuery(myvar) umschreiben und innerhalb der Methode $1 verwenden. Das Problem ist gelöst.

Aber Sie könnten eine wirklich komplexe Methode finden. Tausende von Codezeilen, keine Dokumentation, vor 20 Jahren geschrieben. Und nur einmal pro Jahr verwendet. Das ist eine Menge Arbeit und das Risiko von Fehlern für minimale Auswirkungen. Um das Problem zu umgehen, können Sie sich dafür entscheiden, diesen Code nur im Modus v2004 auszuführen, während Sie alles andere im modernen Modus belassen:

SET DATABASE PARAMETER(Query by formula on server;1)
QUERY BY FORMULA ([Table_2];RunQuery )
SET DATABASE PARAMETER (Query by formula on server;0)

SET DATABASE PARAMETER Mit dieser Funktion können Sie den Modus spontan ändern und müssen sich nicht stundenlang mit selten genutztem Code beschäftigen.

Schließlich sollten Sie prüfen, ob Felder in einer Weise verwendet werden, die die Verknüpfungsfunktion beeinträchtigt. In v2004 wird eine Formel wie [Table_1]Field_2=[Table_2]Field_3 als Suche nach statischen/festen Inhalten interpretiert, wobei der Inhalt von Feld_3 verwendet wird. Nach Aktivierung der Option „QUERY BY FORMULA Uses SQL Joins“ wird dies als Join interpretiert.

Sie müssen also jedes QBF daraufhin überprüfen, ob es einen Feldnamen auf der rechten Seite eines „=“-Operators verwendet. Wenn ja, weisen Sie ihn einer lokalen Variablen zu und verwenden Sie die lokale Variable in der Abfrage.

Nachdem Sie alle Vorkommen von QUERY BY FORMULAüberprüft haben, sind Sie bereit, beide Optionen zu aktivieren.

Genießen Sie die schnelle Suche…