BuildersBuilder
Query & Data Source Builder
Kann continON mit den Datenbanken und Dateien arbeiten, die wir bereits betreiben?
Binden Sie die Datenbanken und Dateien an, die Sie bereits betreiben – SQL Server, PostgreSQL, MySQL, Access und gemeinsam genutzte Dateien –, durchsuchen Sie deren Schema und speichern Sie parametrisierte Abfragen als benannte Objekte. Formulare, Berichte, Dashboards und Dokumentvorlagen lesen alle über dieselben gespeicherten Definitionen.
So funktioniert es
Der Builder verbindet sich mit einer begrenzten Auswahl an Quellen: SQL Server, PostgreSQL, MySQL, Access und andere OleDB-Quellen sowie gemeinsam genutzte Dateien. Er durchsucht das externe Schema direkt an der Quelle, sodass Abfragen gegen die Tabellen erstellt werden, die Sie tatsächlich haben, statt gegen eine Kopie, die jemand exportiert hat.
Was Sie bauen, wird zu einem vollwertigen Objekt. Abfragen, Tabellen, Sichten, Funktionen und Prozeduren werden unter ihrem Namen in einem gemeinsamen Katalog gespeichert, und ihre Parameter liefert zur Laufzeit, was sie aufruft – ein Formular, das eine Auswahlliste füllt, ein Prozess, der einen Schritt ausführt, ein Bericht, der gerendert wird, eine Vorlage, die ein Dokument zusammenführt. Eine Definition bedient alle Abnehmer, statt dass jeder Bildschirm seinen eigenen Datenabruf neu implementiert.
Er enthält zudem einen Tabellendesigner, der echtes Schema schreibt. Definieren Sie Spalten und Constraints, und der Builder erzeugt die Änderung und wendet sie an – Fremdschlüssel eingeschlossen – innerhalb des eigenen Schema-Namensraums Ihrer Organisation. Das ist echte SQL-Generierung, und es ist ein Grund, weshalb continON die Builders als erweiterbare Konfiguration beschreibt und nicht als No-Code-Werkzeug.
Was Sie definieren und was läuft
Eine begrenzte, ehrliche Anbieterliste
SQL Server, PostgreSQL, MySQL, Access/OleDB und gemeinsam genutzte Dateien – die tatsächlich implementierten Anbieter, keine Behauptung, sich mit allem verbinden zu können.
Externes Schema durchsuchen
Tabellen und Spalten einer angebundenen Quelle direkt im Designer prüfen, bevor Sie darauf aufbauen.
An den Kontext gebundene Parameter
Eine gespeicherte Abfrage nimmt Parameter entgegen – darunter die Antrags-, Prozess- und Mitarbeitenden-IDs des Datensatzes, der sie ausführt.
Gespeicherte Objekte, per Name referenziert
Abfragen, Tabellen, Sichten, Funktionen und Prozeduren liegen in einem Katalog, auf den sich jeder andere Builder stützt.
Ein Tabellendesigner, der Schema schreibt
Spalten- und Constraint-Definitionen erzeugen echtes DDL und wenden es transaktional im eigenen Namensraum der Organisation an.
Bei Bedarf direkt in SQL
SQL von Hand schreiben für Fälle, die ein visueller Designer nicht ausdrücken kann – ein ausgewiesener Teil des Modells, keine Ausnahme davon.
Womit das zusammenhängt
- Form Builder
Formularfelder, Wertelisten und Absendeaktionen werden über gespeicherte Abfragen aufgelöst. - Report Designer
Berichte werden aus denselben gespeicherten Abfragen erstellt, sodass die Zahlen mit dem übereinstimmen, was Formulare erfasst haben. - Dashboard Designer
Dashboard-Widgets binden sich an gespeicherte Abfragen oder Ad-hoc-SQL aus diesem Katalog. - Document Template Designer
Vorlagen fügen die Felder einer gebundenen Abfrage in erzeugte Dokumente ein. - Integrationen & Daten
Datenbank- und Dateiverbindungen liegen hier; externe API-Zugangsdaten pro Organisation werden unter Integrationen verwaltet.
Query & Data Source Builder in continON im Einsatz sehen.
Eine geführte Demo auf einem bereinigten Demo-Mandanten – diese Funktion in ihrem Modul, auf der gemeinsamen Plattform.