Buildersbuilder

Query & Data Source Builder

continON peut-il fonctionner avec les bases de données et les fichiers que nous exploitons déjà ?

Connectez les bases de données et les fichiers que vous exploitez déjà – SQL Server, PostgreSQL, MySQL, Access et fichiers partagés –, parcourez leur schéma et enregistrez des requêtes paramétrées sous forme d’objets nommés. Formulaires, rapports, tableaux de bord et modèles de documents lisent tous les données au travers de ces mêmes définitions enregistrées.

Le Query Designer de continON : le référentiel d’objets (tables, vues, procédures et fonctions) à gauche, un éditeur de définition T-SQL avec les indicateurs validé, publié, global et activé, et un panneau de paramètres à droite.
Le Query Designer – le référentiel d’objets, une définition T-SQL avec ses indicateurs de validation et de publication, et les paramètres qu’elle accepte.

Fonctionnement

Le Builder se connecte à un ensemble délimité de sources : SQL Server, PostgreSQL, MySQL, Access et d’autres sources OleDB, ainsi que des fichiers partagés. Il parcourt le schéma externe sur place, de sorte que les requêtes sont composées sur les tables dont vous disposez réellement, et non sur une copie exportée par quelqu’un.

Ce que vous construisez devient un objet à part entière. Requêtes, tables, vues, fonctions et procédures sont enregistrées par nom dans un catalogue commun, et leurs paramètres sont fournis à l’exécution par l’élément qui les appelle – un formulaire qui remplit une liste déroulante, un processus qui exécute une étape, un rapport qui s’affiche, un modèle qui fusionne un document. Une seule définition sert tous les consommateurs, au lieu que chaque écran réimplémente sa propre récupération de données.

Il comprend aussi un concepteur de tables qui écrit un véritable schéma. Définissez colonnes et contraintes, et le Builder génère et applique la modification – clés étrangères comprises – dans l’espace de noms de schéma propre à votre organisation. Il s’agit d’une véritable génération SQL, et c’est l’une des raisons pour lesquelles continON présente les Builders comme une configuration extensible plutôt que comme un outil no-code.

Ce que vous définissez, et ce qui s’exécute

  • Une liste de fournisseurs de données délimitée et honnête

    SQL Server, PostgreSQL, MySQL, Access/OleDB et fichiers partagés – les fournisseurs réellement implémentés, pas la prétention de se connecter à tout.

  • Parcourir le schéma externe

    Inspectez les tables et les colonnes d’une source connectée depuis le concepteur avant de construire dessus.

  • Paramètres liés au contexte

    Une requête enregistrée accepte des paramètres – notamment les identifiants de demande, de processus et de collaborateur de l’enregistrement qui l’exécute.

  • Objets enregistrés, référencés par nom

    Requêtes, tables, vues, fonctions et procédures résident dans un catalogue unique auquel se réfèrent tous les autres Builders.

  • Un concepteur de tables qui écrit le schéma

    Les définitions de colonnes et de contraintes génèrent et appliquent un véritable DDL, de manière transactionnelle, dans l’espace de noms propre à l’organisation.

  • Passer au SQL si nécessaire

    Écrivez le SQL à la main pour les cas qu’un concepteur visuel ne peut pas exprimer – une partie assumée du modèle, pas une exception.

Voir « query & data source builder » fonctionner dans continON.

Une démonstration guidée sur un mandant de démonstration anonymisé – cette fonctionnalité dans son module, sur la plateforme commune.