SQLManagerX
le développement
SQL sous WinDev

Étape 1 : Création de la base de données

La première chose a faire est de créer une base de données sur un serveur (si vous en avez déjà une, vous pouvez directement passer à l’étape 2). Pour cela, vous pouvez soit la créer par vous-même, soit à l’aide du convertisseur (voir le Data Center).

Étape 2 : Création d’un premier projet

Comme premier projet, nous allons simplement créer un ensemble de fenêtres tel que le ferait le RAD pour un fichier HyperFile.

Comme pour tout projet Windev, nous allons le créer à partir de l'AGL. Pour cela faites Fichier > Nouveau et choisissez nouveau projet.

Nommez votre projet SQLMX_1 et cliquez sur Suivant.

Prenez soin de bien sélectionner Aucune analyse puis cliquez sur Terminer.

Cliquez sur OK pour vous rendre directement à l’éditeur WinDev.

Ça y est, notre projet est créé ! Nous allons maintenant pouvoir l'enrichir des composants logiciels livrés avec SQLManagerX.

Étape 3 : Création de l’arborescence projet

Actuellement l'arborescence des notre projet est la suivante :

Pour plus de facilité nous allons créer une arborescence type. Par la suite, nous vous recommandons de la réutiliser pour vos futurs projets.

Faites le nécessaire pour obtenir l'arborescence suivante :

• Le répertoire classes contiendra toutes les classes du projet
• Le répertoire classes_acces contiendra toutes les classes liées aux objets d'accès aux tables par SQLManagerX
• Le répertoire Etats contiendra tous les états.
• Le répertoire Fenetres contiendra les fenêtres.
• Le répertoire Scripts contiendra tous les scripts SQL utilisés dans le cadre de notre développement (script de création de la base, code des classes si vous passez par SQMX-Outils, script des requêtes SQL).

Étape 4 : Copie des fichiers nécessaires

Pour fonctionner avec SQLManagerX, notre projet à besoin des classes et des différents éléments liés à chaque accès natifs.

Dans le répertoire Exe de notre projet, nous devons placer les fichiers DLL suivants :

Nom du fichier	Informations
ado4wd.dll	Accès ado
libmysql.dll	dll Mysql à récupérer sur http://www.mysql.com/ (API propriétaire)
libpq.dll	dll postgresql présente dans le package ou à récupérer sur http://www.postgresql.com/ (API propriétaire)
mysql4wd.dll	dll d'interfaçage entre libmySQL.dll et la c_mysql4wd.wdc
oracle4wd.dll	dll d'interfaçage entre le client Oracle (API propriétaire) et la c_oracle4wd.wdc
postgresql4wd.dll	dll d'interfaçage entre libpq.dll et la c_postregresql4wd.wdc
sqlite4wd.dll	dll d'interface entre la base SQLite et la c_SQLite4WD.wdc
rtl60.bpl	Ressource Borland c++ nécessaire à la dll SQLite4wd.dll disponible dans l'accès SQLite4WD

Pour exploiter, par exemple, SQLManagerX avec une base Mysql, nous devons prévoir l'utilisation des dll libmySQL.dll et mysql4WD.dll.

Dans le répertoire classes, maintenant, nous devons copier les fichiers suivants :

Nom du fichier	Informations
c_ado4wd.wdc	classe pour accès ADO
c_hf4wd.wdc	classe pour accès HF
c_log4wd.wdc	classe de log, nécessaire pour la majorité des accès
c_mysql4wd.wdc	classe pour accès Mysql
c_oracle4wd.wdc	classe pour accès Oracle
c_php4wd.wdc	classe pour accès par PHP
c_postgresql4wd.wdc	classe pour accès Postgresql
c_sqlite4wd.wdc	classe pour accès SQLite
SQLManagerX.wdc

Étape 5 : Intégration des éléments dans le projet

Maintenant que nos fichiers de classes sont présent dans leur répertoire, nous allons intégrer les classes nécessaires dans notre projet. Par exemple, pour MySQL, prévoir c_log4wd.wdc, c_mysql4wd.wdc et SQLmanagerx.wdc.

Étape 6 : Création du code d’initialisation

Nous devons maintenant copier les quelques lignes suivantes dans le code d’initialisation de notre projet :

Notez que l’accès initialisé ici (ligne 2) est un accès MySQL via la classe c_mySQL4WD. Nous aurions tout aussi bien pu nous connecter, via un autre accès, à une autre base en utilisant l’une des lignes de code suivantes :

Pour un accès à une base Postgresql.

Pour un accès à une base Oracle.

Pour un accès ADO.

Pour un accès HFSQL.

L'activation du mode debug convSql:mySQLDebugMode = Vrai permet de tracer les ordres SQL envoyés à la base de données dans un fichier texte à l'aide de la classe c_log4wd.

Attention : si le mode debug est très utile en phase de développement, n’oubliez pas de le désactiver avant déploiement chez le client !

Étape 7 : Création de la classe d’accès villes

Il existe deux possibilités pour créer votre classe : soit vous utilisez l’outil génération de classes du Data Center pour la générer automatiquement, soit vous la créez de toute pièce. Nous vous allons vous présenter tour à tour les deux méthodes.

Création manuelle de la classe c_villes

Déclarez votre classe comme suit :

Remarquez le préfixe c_ suivit du nom de la table pour nommer la classe : c_villes. Notez aussi le préfixe m_ utilisé pour chacun des membres de la classes. Ces deux notion sont primordiales car elles seront reprises dans l'appel du constructeur ci-dessous (respectivement variable p_prefixeClasse et variable p_prefixeMembre).

Il nous reste à écrire le constructeur :

Vous pouvez sauvegarder votre classe dans le répertoire classes_acces que nous avons créé plus haut !

Création assistée de la classe c_villes

Rendez-vous dans le Data Center, ouvrez l’onglet Outils et cliquez sur génération de classes.

Data Center > Outils > Génération de Classes

Entrez le nom villes dans le champ Table, vérifiez que l’option Classe Windev soit bien cochée et cliquez sur Générer.

Maintenant que votre classe a été générée sous forme de fichier .txt, il ne vous reste plus qu’à l’intégrer dans WinDev en copiant sa déclaration et son constructeur présents dans votre fichier .txt.

Étape 8 : Déclaration globale

Ajoutez la ligne suivante dans le code d'initialisation de votre projet juste en dessous de la ligne // Déclaration des classes d'accès à la base :

Ici, quelques explications s’imposent :

I_VILLES est notre instance de la classe C_VILLES (objet disponible dans le TreeView des objets du projet).

Lors de son instanciation, I_VILLES va utiliser la connexion principale d'accès à MySQL (définie explicitement dans le code du projet) : convSql. Le nom de la table accédée en base est villes et on rappelle à l'objet SQLManagerX que le nom de notre instance est I_VILLES. Le dernier paramètre de la classe étant le nom de l'objet, vous devez donc avoir une ligne commençant et terminant par le même nom, comme c’est le cas ci-dessus.

Concernant le nom de la table accédée suivant l'accès et l'OS, il faut respecter la casse de la table (sous Mysql avec les tables innodb, veillez à toujours utilisez des minuscules, ceci afin de pouvoir basculer sans entrave d'un système Unix à Windows et inversement).

Étape 9 : Création de notre première fenêtre en mode Fiche

Nous allons créer une fenêtre vierge avec 3 champs :

• un champ de saisie Commune, de type texte sur n caractères
• un champ de saisie CodeP, de type texte sur n caractères
• un champ de saisie Zone, de type numérique sur 4 octets

Vous devriez obtenir quelque chose comme ça :

Ajoutez également un bouton Fermer pour plus de facilité puis enregistrez cette nouvelle fenêtre dans votre répertoire Fenetres en la nommant Fiche Villes.wdw.

Étape 10 : Insertion de la fonction d’affichage

Dans le bloc de Déclaration globales, saisissez les 2 lignes suivantes :

Notez que nous avons mis le nom de la fenêtre courante en paramètre de la fonction (méthode) SQLTableVersEcran(). Ceci vient du fait que nous nous trouvons dans le code de déclarations globales. Si nous étions dans le code Initialisation, cela n'aurait pas été nécessaire. Nous vous recommandons néanmoins de toujours utiliser cette manière de faire.

Pourquoi, nous demanderez-vous ? En voici l'explication :

Soit une fenêtre appelante et une fenêtre appelée. Dans le code Initialisation de la fenêtre appelée, la fonction FenEnCours() renvoie le nom de la fenêtre appelante ! Par défaut, c'est cette fonction qui est utilisée dans SQLTableVersEcran() si le nom de la fenêtre n'est pas passé en paramètre. C'est pour cette raison que nous conseillons de toujours passer en paramètre le nom de la fenêtre.

Étape 11 : Insertion des boutons mode parcours

Nous allons maintenant créer 4 boutons de parcours avec leur codes associés.

Un bouton Premier, pour se positionner sur le premier enregistrement&nbs;:

Un bouton Précédent, pour se positionner sur l’enregistrement précédent :

Un bouton Suivant, pour se positionner sur l’enregistrement suivant :

Et enfin un bouton Dernier, pour se positionner sur le dernier enregistrement :

Votre fenêtre devrait maintenant ressembler à ça :

Lancez un GO du projet et testez le parcours de la table.

Étape 12 : Insertion des boutons nouveau, modifier et supprimer

Tout comme nous avons créé les quatre boutons mode parcours, nous allons maintenant créer les boutons nous permettant d’ajouter, de modifier et de supprimer des entrées dans notre table.

Créez tout d’abord un bouton Nouveau avec ce code associé :

La méthode SQLEcranVersTable permet de transférer les données depuis les champs de la fenêtre vers les membres de votre objet.

La méthode SQLInsert permet quant à elle de transférer les valeurs des membres de votre objet dans la base de données.

Créez ensuite un bouton Modifier avec ce code associé :

La méthode SQLUpdate() permet de transférer les valeurs des membres modifiés de votre objet dans la base de données. Seules les valeurs modifiées sont transférées dans l'ordre update à la base de données.

Et créez ensuite un bouton Supprimer avec ce code associé :

Vous pouvez lancer un Go du projet et tester les nouvelles actions proposées.

Étape 13 : Création de notre première fenêtre en mode Table (alimentation en mode fletch global)

Créez une fenêtre vierge et insérez-y un bouton Fermer avec le code associé.

Créez ensuite une table mémoire Table1 avec 2 colonnes (une colonne numérique et une colonne texte). Nous n'allons pas définir de code associé à cette table.

Enfin, créez un nouveau bouton avec le code associé suivant :

Dans notre exemple, on remarque que nous avons appliqué en première ligne un filtre pour ne prendre en compte que les produits dont l'identifiant est contenu entre 100800 et 100900.

Un filtre se déclare tout simplement à l'aide de la méthode SQLFiltre. Le premier paramètre lié à cette méthode correspond à la future clause de restriction sans le mot clé WHERE, le second paramètre correspond à l'ordre dans lequel les éléments doivent être lus (le ORDER BY).

Une annulation de filtre est effectuée au moyen de la méthode SQLFiltre("","") ou plus simplement SQLFiltre().

La méthode DesactiveFiltre() désactivera temporairement le filtre que vous aurez précédemment créé alors que la méthode ActiveFiltre(), quant à elle, le réactivera.

En seconde ligne, la méthode utilisée est très simple : SQLCTable. On lui passe en paramètre la table mémoire cible ainsi que les colonnes à afficher séparées pas des virgules.

Attention : Toutes les colonnes retournées par la requête doivent être nommées. Le symbole * (généralement utilisé pour récupérer toutes les colonnes dans une requête SQL) n'est pas autorisé ici.

L'intérêt de cette méthode, au contraire de la suivante, est l'utilisation des loupes et des tris dans la table.

Étape 14 : Création de notre première fenêtre en mode Table (alimentation en mode fletch partiel)

Malgré l'intérêt de la méthode précédente, son mode de fonctionnement intrinsèque (le fait que toutes les lignes de la requête soient systématiquement chargées en mémoire) représente un inconvénient majeur : le traitement peut être lent si la requête renvoie beaucoup de lignes.

C'est pour palier à ce problème que SQLManagerX propose une méthode, dite à fetch partiel, permettant au nombre de lignes ramené par la méthode d'être égal au nombre de lignes dans votre table.

Voyons cela tout de suite !

Créons une fenêtre vierge et insérons-y comme d'habitude notre bouton Fermer avec le code qui lui est associé.

Créons ensuite une table mémoire Table1 avec 2 colonnes (une colonne numérique, une colonne texte).

Maintenant, créons un ascenseur Ascenseur1. Mettez-le un peu en forme pour qu'il ait la même hauteur que votre table et qu'il soit collé à elle sur sa droite.

Créons un bouton avec le code associé suivant :

Ajoutons également la ligne de code suivante à notre ascenseur:

Et pour finir, ajoutons le code suivant à notre table :

On remarque que le parcours initial ne diffère pas tellement de la méthode précédente hormis l'utilisation de la méthode TableAffiche.

On remarque aussi l'utilisation de cette méthode TableAffiche à chaque modification de valeur de notre ascenseur Ascenseur1. Rien de plus normal car c'est le fonctionnement attendu d'un ascenseur dans une table : celui-ci permet le parcours dans la table.

Pour finir, une nouvelle méthode XtableGereTouche a été associée à notre table. Cette méthode nous permet de mettre à jour la valeur courante de notre ascenseur en fonction des touches appuyées (haut, bas, ‘page up', ‘page down') puis de réafficher la table.

Un pdf complet du guide du développeur est à votre disposition ici. Vous y trouverez en détail l’ensembles des différents membres avec leur utilisation ainsi que l’ensemble des méthodes utilisées par SQLManagerX.

Téléchargez ici le guide du développeur en format pdf.

Un pdf complet du guide de l’utilisateur est à votre disposition ici. Vous y trouverez toute la documentation nécessaire pour utiliser SQLManagerX à travers l’environnement Windev et les différente SGBD.

Ce guide vous accompagnera que vous soyez totalement novice ou non en Windev et que vous ayez déjà expérimenté ou non SQLManagerX. Vous y découvrirez entre autre les différents accès [alter]natifs et comment les utiliser afin d’accéder à vos données sans utiliser de SQL.

Téléchargez ici le guide de l’utilisateur en format pdf.

Ce projet vous montre un exemple de développement avec SQLManagerX.

Il y a deux fenêtres modèles qui permettent de créer les nouvelles fenêtre (table et fiche). On ouvre la fenêtre et on fait enregistrer sous pour lui donner un autre nom. Il ne reste plus qu'a modifier la table ou les champs pour qu'ils correspondent a l'objet SQLManagerX et à éditer le code d'init de la fenêtre pour lier l'objet (le nom de l'objet SQLManagerX concerné).

Ce projet est fonctionnel et vous permet de voir comment le code est exécuté.

Par exemple sur la fenêtre w_client_table, vous pouvez très facilement ajouter un champ de recherche. Il suffit de créer un nouveau champ, de le nommer correctement (charte de programmation) et de lancer le programme pour que la table s'alimente avec un filtre sur ce champ.

Téléchargez ici le projet d’exemple.