Dans les rouages de SQLManagerX

Nous vous présentons ici la classe SQLManagerX dans le détail. De la générations de vos tables aux personnalisations de vos requêtes en par les fonctions GET et SET ou encore des explications plus poussées sur le Mapping Objet Relationnel, vous saurez tout sur SQLManagerX.

+ d'infos

dataXmaster est une sollution conçue pour extraire, synchroniser et transformer vos données sans développement.

Pour nous aider a maintenir toute la partie gratuite de SQLManagerX qui reste l'occupation principale de ses membres.

Cette chaine a été créer afin d’illustrer par des vidéos les différents accès que nous mettons à disposition sur ce site.

SQLManagerX Pro est là pour offrir aux professionnels un ensemble prestations (développements, formations, audits...)

Les accès [alter]natifs sont le lien entre les accès de bas niveau de l’éditeur SGBD et votre application WinDev.

Si vous utilisez SQLManagerX et/ou les accès [alter]natifs, vous pouvez faire partie de nos références !

Vous êtes convaincu des bienfaits de SQLManagerX pour votre projet ? Il ne vous reste plus qu'à l'utiliser.

Vous souhaitez un peu d'aide pour mieux démarrer avec SQLManagerX ? Guides et exemples sont là pour vous.

SQLManagerX en Bref

Ce site est un espace non officiel consacré au développement SQL sous WinDev.
Notre solution, SQLManagerX, est entièrement gratuite et accessible aux développeurs internautes.

Vous pouvez télécharger SQLManagerX ici

Bienvenue dans les rouages de SQLManagerX !

Une charte de programmation vous permet de gagner du temps et d'assurer plus facilement la maintenance de votre projet. Plus celui-ci sera volumineux et plus une charte de programmation s'imposera.

Windev 10 vous permet de mettre une telle charte en place. Celle-ci devra alors être connue de SQLManagerX pour lui permettre de s’y adapter et de suivre vos fenêtres.

C’est la constante :charteProg qui vous permet de spécifier une charte pour votre projet et qu’il vous faudra peut-être modifier si vous souhaitez appliquer votre propre charte de programmation. Celle-ci reprend tous les préfixes appliqués aux noms de vos objets en respectant le principe simple qu’à chaque nom de champ de la fenêtre correspond le nom de la colonne dans la table SQL. SQLManager est alors capable de réaliser tous les tableVersEcran et ecranVersTable attendus.

Exemple :

Les champs de saisie d’une fenêtre sont préfixés SAI_ par Windev. Afin que SQLManagerX puisse les identifier comme tels, il vous suffit de rajouter SAI, dans sa constante.

La charte définie par défaut est la suivante :

Type d’objet Abréviation
Libellés Lbl_
Champs de saisie Edt_
Boutons Btn_
Tables mémoires Tbl_
Listes Lbx_
Combos Cbb_
Sélecteurs Cbx_
Interrupteurs Rbx_
Groupe d’options Fbx_
Ascenseur horizontal Hsb_
Ascenseur vertical Vsb_
Jauge Pbr_
Barre de curseur Sbx_
Arbre de visualisation Trv_
Onglet Tab_
Champs RTF Rtf_
Image Img_
Champs OLE Ole_
ActiveX Ocx_
Forme (ligne…) Frm_
Champs html Htm_
Super champs spr

La constante reprend tous ces préfixes afin que SQLManagerX puisse correctement identifier les champs appartenant aux tables SQL :

k_CharteProg = ",EDT,RTF,IMG,LBL,CBB,CBX,RBX,FBX,LBX,VSB,HSB,PBR,SBX,TRV,TAB,TBL,OLE,OCX, FRM,HTM,SPR"

Attention : il est impératif de bien laisser la première virgule dans la constante. En effet, c’est cette virgule qui permet de gérer les champs sans préfixe. Ensuite vous pouvez ajouter tout ce que vous voulez.


Les 3 méthodes GET et les 3 méthodes SET de SQLManagerX vous permettent de modifier le comportement de la classe sur les clés primaires, les valeurs null, les auto-incréments, etc.

GetPrimaryKey :

Cette méthode vous permet d'obtenir, sous forme de chaine et séparés par des virgules, les noms des colonnes relatives à la clé primaire.

SetPrimaryKey :

Cette méthode vous permet de modifier la liste des colonnes faisant partie de la primary key.

Exemple : client:SetPrimaryKey("client_ID, Nom") définira clientId et Nom comme des clés primaires.

Les colonnes définies comme clés primaires à l’aide de SetPrimaryKey seront dès lors utilisées par SQLManagerX pour construire, par exemple, le where de ses requêtes update.

Pour réinitialiser la valeur par défaut, utilisez setPrimaryKey() sans argument.

GetNotNull :

Cette méthode vous permet de d’obtenir, sous forme de chaine et séparés par des virgules, les noms des colonnes définies non null dans votre base SQL.

SetNotNull :

Cette méthode vous permet de modifier la liste des colonnes définies non null.

Exemple : client:SetNotNull("client_ID, Nom") définira clientId et Nom comme des colonnes non null.

Lors de la construction de ses requêtes, SQLManagerX vérifiera que les valeurs sont bien non null pour les exécuter. Depuis sa version 5, SQLManagerX permet également de lancer une fenêtre info dans le cas où le champ nom dans la fenêtre serait vide.

Pour réinitialiser la valeur par défaut, utilisez setNotNull() sans argument.

GetAutoIncrement :

Cette méthode vous permet d’obtenir, sous forme de chaine, les noms des colonnes définies autoIncrement dans votre base SQL

SetAutoIncrement :

Cette méthode vous permet de modifier la liste des colonnes autoIncrement.

Exemple : client:SetAutoIncrement("client_ID, NumSS) définira client_ID et NumSS comme autoIncrement.

Pour ce qui concerne les autoIncrement, SQLManagerX ne transmet aucune colonne au serveur, qui se charge lui-même de remplir la base avec la dernière valeur incrémentée. Cette méthode est surtout importante si l’accès ne détecte pas vos colonnes autoIncrement (par exemple sous firebird). Dans ce cas, il reste possible de le spécifier après la déclaration de l’objet.

Pour réinitialiser la valeur par défaut, utilisez setAutoIncrement() sans argument.


Il est parfois utile dans un champ, suivant ce que saisit l'utilisateur, de se positionner directement sur la ligne recherchée ou au moins sur la valeur en base la plus proche.

Avec la méthode SaisieAssistee, SqlManagerX vous offre cette fonctionnalité.

À chaque modification d’entrée dans un champ (par exemple celui correspondant au nom du client), ce code peut-être appliqué :

Message()
SI client:SaisieAssistee("nom","Saisie1") ALORS Message("Trouvé")

L’effet obtenu est alors le remplissage du champ (dans lequel l’utilisateur est en train d’effectuer sa saisie) par la valeur la plus proche présente en base. Bien sûr, SQLManagerX gère la requête et le résultat en toute transparence.

Cette option peut s’avérer très utile pour contrôler la saisie d'une recherche.

ATTENTION : si toutefois la table possède un grand nombre de lignes et/ou si la colonne ne fait pas partie d'un index, cette action peut prendre plus de temps que voulu et ennuyer l’utilisateur plus qu'elle ne lui rend service.

Extrait de la documentation SQLManagerXDocRef :

Objet : saisieAssistee(colonne,champs)
Objet : objet SQLManagerX, nom de l’objet table SQLManagerX (ex. Client)
Colonne : chaîne de caractère correspondant au nom de la colonne dans la base SQL
Champ : chaîne de caractère correspondant au nom du champ dans la fenêtre windev


La fonction SQLDump de SQLManagerX vous permet de réaliser vos dump très facilement. Pour tout objet SQLManagerX, vous pouvez sauver l’intégralité ou partie de la table correspondante. SQLDump vous permet de générer un ou plusieurs fichiers avec ou sans les create table, etc.

Cette fonction est très utile lorsqu’il s’agit de sauvegarder la structure de votre base et, le cas échéant, reconstruire une base propre et vierge de toutes données.

Par expérience, nous recommandons d’utiliser deux fichiers. Un premier pour générer le script de la base et un second contenant les données. Vous obtiendrez ainsi des procédures de sauvegarde et de restauration automatiques.

Un des avantages se trouve également dans le paramètre condition qui permet de mettre un where sur les données que l'on désire sauvegarder.

Attention : si pour des tables moyennes ou des bases de petites tailles, SQLDump s’avère une méthode très efficace, des tables comportant beaucoup d’enregistrements peuvent être très longues à dumper.

Les paramètres de la fonction sont les suivants :

p_FichierDest Chemin et nom complet du fichier de destination
p_bEnAppend Vrai = Ouvrir le fichier de destination et ajouter à la fin
Faux = Ouvrir le fichier en création (vide)
p_Condition Condition SQL à appliquer sur les données à exporter
p_NumRequete N° de requête à utiliser
p_Jauge Nom du champ de la barre de progression (optionnel)
p_Drop Booleen stipulant si le DROP table doit être mis dans le fichier
p_Data Si vous ne voulez pas avoir les datas, par exemple pour ne sauver que la structure de votre base, vous pouvez mettre le paramètre a faux. Vous n’obtiendrez alors que les create table.

SQLManagerX vous aide à récupérer la structure de vos tables afin de mieux personnaliser vos requêtes.

SQLManagerX possède sa méthode propre permettant de générer un select sur une table. Toutefois, si vous ne voulez pas faire select * mais nommer chaque colonne, SQLLigneSelect peut vous aider dans votre tache.

SQLLigneSelect(VerspressePapier,AjouteNomTable)

Les paramètres sont tous deux des booleen.

maChaine = client:SQLLigneSelect()

Le code ci-dessus vous renvoie la ligne suivante :

client.client_ID,client.titre,client.nom,client.adresse,client.adresseSuite,client.codePostal, client.ville,client.telephone,client.fax,client.memoClient

maChaine = client:SQLLigneSelect(faux,faux)

Le code ci-dessus vous renvoie la même ligne que précédemment mais sans le nom de la table devant les noms des colonnes :

client_ID,titre,nom,adresse,adresseSuite,codePostal,ville,telephone,fax,memoClient

Structure des tables :

Vous pouvez obtenir le schéma d’une table à l’aide de la commande : GetSchema()

client:GetSchema()
createTable = client:ShemaTable
createIndex = client:ShemaIndex

Attention : le schéma étant dépendant de la base, une même action sur une base mySQL ou Oracle ne renverra pas la même chaine en retour. Cela est vrai en particulier pour les type de colonnes.


Avec la fonction SQLTableEdit de SQLManagerX, une seule ligne suffit pour vous permettre d’éditer une table dans une fenêtre.

Votre fenêtre contient une table chargée par les méthodes SQLXtable ou SQLCtable de SQLManagerX et vous souhaitez une édition propre de cette table sans créer un Etat ? Alors SQLTableEdit est fait pour vous !

Exemple :

Une table a été chargée dans une fenêtre grâce à la commande suivante :

TableSupprimeTout(tbl_client)
client:SQLFiltre("codePostal like '91%","order by client_ID")
client:SQLXtable("tbl_client","asc_client",v_colonne,Vrai)
client:SQLTableAffiche()

Pour obtenir une édition de cette table, il n’y a plus qu’à ajouter un bouton et y attacher le code suivant :

client:SQLTableEdit("Liste des Clients")

L’option paysage vous permet d’afficher cette édition en format paysage :

client:SQLTableEdit("Liste des Clients","PAYSAGE")

Ça y est, l’édition est maintenant construite par SQLManagerX avec un état générique SQLEtat (ou SQLEtatP si l’option paysage a été choisie).

Désormais, vos fenêtres tables peuvent proposer une édition sans pour autant nécessiter quelque développement supplémentaire ou la génération d'un état.


La méthode tableConstruit de SQLManagerX vous permet de générer dynamiquement une nouvelle table à partir des données d'une table SQL déjà présente dans votre base de données.

Si vous souhaitez apporter des modifications à votre table, alors la méthode TableConstruitEnregistre vous permet d'enregistrer les valeurs sous forme d’update ou d’insert.

La méthode TableConstruitEnregistre est donc utilisée pour enregistrer une ligne ou la table complète préalablement construite à l’aide de la méthode tableConstruit.

Le principe est simple : on affiche la table, on modifie les données puis on enregistre.

L'avantage de cette procédure est qu’en utilisant ses propres méthodes, SQLManagerX s’occupe uniquement des valeurs qui ont changé.

L'application de cette méthode est visible dans le Data Center. En voici un extrait du code afin d’illustrer avec quelle simplicité s’opère l'affichage d'une ligne et son enregistrement :

v_indice est un entier = Table1
o_sqldynamique:TableConstruitEnregistre("table1",v_indice)
SI o_sqldynamique:derniereRequeteExecutee <> "" ALORS
SI o_sqldynamique:ErreurSQL <> "" ALORS
Info(o_sqldynamique:ErreurSQL)
SINON
Info("Enregistrement effectué")
FIN
FIN

Le code ci-dessus est celui correspondant au bouton enregistrer la ligne en cours. On ne s'occupe donc pas de savoir quelle valeur a changé ou non, c’est SQLManagerX qui s'occupe de tout.

Couplé a la méthode tableConstruit, tableConstruitEnregistre vous permet de gérer les tables en saisie très facilement.


Vous trouverez ici la page nous ayant inspiré pour cette partie : http://morpheus.developpez.com/persistentdatasets/

Aux vues de toutes les fonctionnalités que doit avoir un logiciel de Mapping Objet / Relationnel, SQLManagerX n’a pas la prétention de toutes les respecter. Il est néanmoins intéressant que vous sachiez que certains « grands » concepts peuvent être rejoins à travers Windev.

Le concept Mapping Objet / Relationnel (ORM)

Il s’agit d’une interface représentant les données stockées dans une base de données relationnelle sous forme d’objets dans votre application. On dit qu’un logiciel de Mapping Objet / Relationnel est une couche de persistance connectant des objets à des données en base.

Une couche de persistance est en quelque sorte un middleware à votre projet qui se chargera de représenter chacune de vos tables en classes. C'est grâce à cette couche de persistance que vous allez pouvoir appeler des méthodes de votre classe, qui seront en fait des méthodes agissant directement sur votre base de données (méthodes Save, Update, etc.).

En quoi cela concerne SQLManagerX ?

Comme vous le savez maintenant, SQLManagerX permet de gérer une table de votre base de données en un objet, chaque colonne étant représentée par un membre.

La classe SQLManagerX est notre couche de persistance. C’est elle qui transforme une demande de mise à jour en un ordre SQL UPDATE en base, ou encore un ordre de création en un ordre INSERT en base.

Exemples :

Sélection avec critère :

I_Clients est un C_Clients
I_Clients:SQLFiltre("Nom like ''%A%'')

Ordre SQL envoyé à la base :

“SELECT Nom, Prenom, Age, Ville FROM Clients where Nom like ''%A%''”

Ajout d’un enregistrement :

I_Clients est un C_Clients
I_Clients:m_nom = ''LEBRUN''
I_Clients:m_prenom ''Thomas''
I_Clients:SQLInsert()

Ordre SQL envoyé à la base :

“INSERT INTO Clients (Nom, Prenom) values (''LEBRUN'', ''Thomas'');”

Modification d’un enregistrement :

I_Clients est un C_Clients
I_Clients:m_id_client = 10
I_Clients:m_nom = ''LEBRUN''
I_Clients:m_prenom = ''Thomas''
I_Clients:m_ville= ''PARIS''
//… dans la fenetre l’utilisateur modifie la ville de Paris par Lille
I_Clients:SQLEcranverstable()
I_Clients:SQLUpdate()

Ordre SQL envoyé à la base :

''UPDATE Clients set ville='LILLE' values WHERE ID_client=10;''

On voit bien que la requête prend seulement en compte la partie modifiée par l'utilisateur. Les autres valeurs ne sont pas updatées puisqu'elles n'ont pas changées.

Conclusion

Vous constatez que l’on peut ignorer certains principes utilisés dans d’autres langages tout en les utilisant de manière quotidienne, par exemple avec SQLManagerX.


Avec la possibilité de modifier la base (suppression ou ajouts de colonnes sur une table, par exemple) sans avoir à relivrer immédiatement votre application, SQLManagerX s’efforce à détacher au mieux l’analyse (au sens Windev) de la partie application. Dans le cas d'une suppression de colonne le champ à l'écran sera simplement ignoré par SQLManagerX.

Cette approche vous permet, entre autre, de faire évoluer votre base (ajout de colonne, par exemple) et d’en tenir compte dans la future évolution de votre application sans pour autant mettre à mal les anciennes versions. Ces dernières continueront à fonctionner correctement !