Nous avons rappelé dans la note Localisation des objets Paradox dans les alias l'importance d'utiliser des alias et précisé quelques règles permettant de répartir les objets Paradox dans ceux-ci. Nous nous préoccupons ici de la gestion proprement dite de ceux-ci.

La première solution est de définir les alias dans le fichier (idapi.cfg) de configuration du BDE (alias public). Nous avons déjà évoqué le rôle de ce fichier dans la note technique relative au paramétrage de l'IDAPI. La solution consiste à utiliser le même fichier de configuration pour l'ensemble des postes devant accéder à l'environnement Paradox et à définir dans le fichier idapi.cfg (ou le nom que vous lui donnerez) les chemins associés aux alias. Un inconvénient, sensible si vous prévoyez de déployer votre application dans un environnement que vous ne connaissez pas, est la nécessité de définir des chemins absolus pour chaque alias.

La solution que nous développons ici repose sur une gestion totalement dynamique des alias par l'application elle-même. Pour cela, nous allons définir une table, que nous appelerons par exemple ALIAS.DB dans laquelle nous allons indiquer nos différents alias et leur localisation. Un script de démarrage de l'application (nous appelerons ce script DEBUT.SSL) aura pour fonction de charger en mémoire les alias. Un des avantages de cette solution est de pouvoir travailler avec des chemins relatifs (par rapport au répertoire où se trouve le script alias par exemple).

Nous évoquerons en fin de cette note quelques autres possibilités offertes par cette solution.

Dans l'exemple que nous allons prendre, les chemins relatifs seront exprimés par rapport à la localisation du script DEBUT (la table ALIAS est située dans le même répertoire que le script DEBUT). Nous préférons en effet cette solution à l'utilisation de l'alias TRAVAIL en raison du changement de nom de ce dernier selon les versions de Paradox (TRAVAIL ou WORK pour Paradox 10, les paris sont ouverts!). De la même façon, nous allons créer un alias que nous appelerons -MAITRE et correspondant à cette localisation de départ. Nous utiliserons systématiquement l'alias -MAITRE en lieu et place de TRAVAIL ou WORK pour éviter toute mauvaise surprise.

 

Remarque: Nous aimons bien commencer nos noms d'alias par un "-" car les alias ainsi nommés ne peuvent pas être créés autrement que par programmation; cela garantie des noms d'alias qui ne peuvent entrer en conflit avec un nom d'alias public (défini dans le fichier idapi.cfg de configuration du BDE).

 

Notre script va tout d'abord créer l'alias -MAITRE.

Le script ouvre ensuite la table ALIAS.DB et parcourt cette table en créant pour chaque enregistrement l'alias correspondant. Vous constaterez qu'il constitue le nom physique complet du répertoire associé à l'alias. Dans le cas d'un alias local, les chemins sont relatifs au répertoire privé. Si le répertoire local n'existe pas le script se chargera de créer le répertoire.

1) Si vous localisez vous objets distribués dans des répertoires différents de ceux des sources, rien n'empêche de gérer dynamiquement ce paramètre dans le script. Par exemple, si l'extension du script est SSL, vous utilisez le répertoire indiqué dans la table, en revance si l'extension est SDL, vous pouvez utiliser un sous-répertoire fonction par exemple de la version de Paradox que vous utilisez (716 pour Paradox 7 16 bits, 732 pour Paradox 32 bits, 832 pour Paradox 8, 932 pour Paradox 9) ;

2) Si vous utilisez des bases de données autres que Paradox ou Dbase, vous pouvez ajouter une zone Pilote qui précisera le type la base de données, les paramètres de connexion de chaque alias étant précisés dans une seconde table ;

3) Si vous souhaitez diminuer la charge de votre réseau, vous pouvez dupliquer localement les répertoires non modifiables en exploitation (les programmes en particulier). Vous ajouterez dans ce cas un indicateur pour repérer ce type d'alias et un champ DateTime permettant de dater le répertoire du serveur. Au chargement, si le répertoire local n'existe pas où si la date du répertoire local (date qui sera mémorisée dans une table ou un fichier local au poste) est antérieure à la date du serveur, le contenu du répertoire du serveur sera recopié localement ;

4) Si des alias de sont utilisés qu'en développement, vous pouvez éviter de charger ceux-ci en ajoutant un indicateur ;

5) Vous pouvez vérifier que l'alias pointe vers le bon répertoire en contrôlant la présence d'un fichier témoin dans celui-ci ;

6) Vous pouvez gérer les alias de toutes vos applications dans une même table et filtrer selon l'application que vous lancez ;

 

et bien d'autres possibilités en fonction de votre environnement de travail, de votre application et de votre imagination ...

 

Si cette solution peut paraître un peu longue la première fois, vous profiterez dès votre seconde application de la souplesse qu'elle procure, alors n'hésitez pas, gérer vos alias en table...