> For the complete documentation index, see [llms.txt](https://docs.ninox.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ninox.com/ninox-scripting/de/automate-your-workflows/automations/understand-transactions-in-ninox.md). # Transaktionen in Ninox verstehen Erfahre, wie Ninox Lese- und Schreibtransaktionen ausführt. Ninox führt Datenbankaktionen als Transaktionen aus. Eine Transaktion fasst eine oder mehrere Operationen in einem Ausführungsschritt zusammen.\ In der Praxis verarbeitet Ninox das Lesen und Ändern von Daten unterschiedlich. ## **Lesetransaktionen** Eine Lesetransaktion ruft Daten ab, ohne sie zu ändern. Typische Beispiele sind: * Datensätze in einer Tabelle filtern * eine Abfrage ausführen, um passende Datensätze zu finden * Werte lesen, um sie in der App anzuzeigen Wenn Ninox eine Lesetransaktion startet, arbeitet sie mit dem Datenstand, der zu diesem Zeitpunkt aktuell war. Änderungen, die andere Nutzer während derselben Abfrage speichern, sind nicht Teil dieses Ergebnisses. Ninox kann viele Lesetransaktionen gleichzeitig verarbeiten. Wenn ein Nutzer Daten liest, blockiert das normalerweise keinen anderen Nutzer beim Lesen von Daten. ## **Schreibtransaktionen** Eine Schreibtransaktion ändert Daten. Typische Beispiele sind: * einen Datensatz erstellen * einen Feldwert bearbeiten * einen Datensatz löschen * auf eine Schaltfläche klicken, die Daten aktualisiert * Logik ausführen, die Werte in die Datenbank zurückschreibt Es läuft immer nur eine Schreibtransaktion gleichzeitig. Andere Schreibtransaktionen warten, bis die aktuelle abgeschlossen ist. Das ist normalerweise kein Problem, weil die meisten Schreibtransaktionen sehr schnell abgeschlossen sind. {% hint style="info" %} Automatisierungen wie **Bei Erstellung** und **Bei Aktualisierung** laufen innerhalb derselben Schreibtransaktion, die sie ausgelöst hat. {% endhint %} ## Nutze Transaktionen für eine App mit hoher Performance Gute Ninox Logik liefert mehr als nur das richtige Ergebnis. Sie sollte auch vorhersehbar laufen, andere Nutzer nicht blockieren und leicht zu pflegen sein. Wenn Ninox langsam oder kurzzeitig nicht reagiert, blockiert möglicherweise eine längere Schreibtransaktion die Warteschlange. Das passiert, wenn eine Aktion deutlich länger als üblich dauert und spätere Schreibaktionen warten müssen.\ Häufige Ursachen sind: * Aufrufe externer Dienste, zum Beispiel mit `http(...)` * große Datenauswertungen kombiniert mit `select` * komplexe Logik in Schaltflächen oder Automatisierungen, die viele Datensätze aktualisiert Vermeide diese Ursachen, indem du die Schreiblogik fokussiert und kurz hältst. Befolge diese Faustregeln: * Lies und bereite Daten zuerst vor, wenn möglich. * Halte API-Calls, wenn möglich, aus kritischen Schreibabläufen heraus. * Vermeide wiederholte `select`-Abfragen innerhalb von Schleifen. * Teste Schaltflächen und Automatisierungen mit realistischen Datenmengen. * Teile große Aktualisierungen, wenn möglich, in kleinere Schritte auf. Eine praktische Denkweise: * Verwende Lesetransaktionen, um Daten zu prüfen. * Verwende Schreibtransaktionen nur, wenn du eine Änderung speichern musst. * Je weniger Arbeit eine Schreibtransaktion ausführen muss, desto flüssiger fühlt sich die App für alle an. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.ninox.com/ninox-scripting/de/automate-your-workflows/automations/understand-transactions-in-ninox.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.