Les alias sont utilisés dans Paradox pour s'affranchir de la localisation physique des objets manipulés. Un alias donné pointe soit vers un répertoire (pilote alias de type standard), soit vers une base de données externe (oracle par exemple, pour les autres types de pilote ). Nous nous intéressons ici au premier cas et allons essayer de vous fournir quelques conseils dans l'utilisation des alias.

 

Qu'est-ce qu'un alias:

 

Un alias est un nom logique associé à un chemin d'accès. Vous pouvez utiliser le nom d'alias à la place du chemin d'accès pour référencer vos objets. Par exemple, si vous référencer la table C:\ Corel\ Suite8\ Paradox\ Exemple\ Clients.db dans le modèle relationnel d'une fiche, vous pouvez, si vous avez défini un alias 'Exemple' pointant sur le répertoire "C:\ Corel\ Suite8\Paradox\ Exemple", utiliser la syntaxe :Exemple:Clients.db pour référencer votre table.

Remarque: Pour utiliser un alias, on encadre son nom du caractère : .

 

Pourquoi utiliser des alias:

 

Tout d'abord, on peut tout à fait se passer des alias et utiliser les chemins complets. Mais dans ce cas que se passe-t-il si vous avez besoin de changer pour une raison ou une autre la localisation de vos objets Paradox ? Eh bien, il est nécessaire de reprendre toutes vos fiches, états, requêtes et de mettre le chemin correspondant à votre nouvelle localisation. Si vous avez une cinquantaine de fiches et autant d'états (cela arrive plus vite qu'on ne croit), vous allez très vite comprendre la notion d'alias.

 

Si vous avez pris la précaution d'utiliser la notion d'alias, il suffit de changer les répertoires associés à ceux-ci, par exemple via le menu Ouitls/Gestionnaire d'alias, ce qui prend quelques secondes, et le travail est fini. Dans le cas contraire, vous devez réouvrir toutes vos fiches, états et requêtes pour réadresser les tables correctement, ce qui va vous prendre quelques heures. Profitez-en pour créer les alias à ce moment-la (il vaut mieux éviter que l'histoire ne se répète pas).

 

Dans le cas d'applications devant être utilisées en réseau local, l'utilisation des alias est une nécessité. En effet, le chemin physique d'accès peut non seulement varier dans le temps mais également suivant les postes (les disques logiques correspondant aux ressources partagées du serveur peuvent porter des noms différents d'un poste à l'autre).

 

En conclusion, utilisez systématiquement les alias, ainsi vous n'aurez jamais à regretter de ne pas les avoir utilisés !

 

Quels alias faut-il définir:

 

Vous avez pris la (bonne) décision d'utiliser des alias. Mais combien en faut-il ? En créer un pour les tables, un pour les fiches, un pour les états, un pour Pierre et un pour Jacques, ... . ?

 

Tout d'abord, il faut savoir que Paradox créé systématiquement deux alias :PRIV: et :WORK: que vous pouvez bien sûr utiliser. Nous décrivons dans le paragraphe suivant le rôle de ces alias.

 

Nous vous indiquons ensuite quels sont nos critères pour la définition des alias. Vous pourrez ensuite appliquer ces critères à votre contexte et construire votre application avec une architecture de répertoire totalement évolutive.

L'architecture théorique que vous obtenez par application de l'ensemble de nos critères (auxquels vous pouvez ajouter les vôtres) peut souvent être simplifiée pour obtenir l'architecture définitive. Nous abordons à la fin de la présente note quelques règles de simplification que nous utilisons.

 

Les alias :PRIV: et :WORK:

 

L'alias :PRIV: (attention, dans certaines versions, il s'appelle :PRIVE: ) est le répertoire dans lequel Paradox va stocker toutes les tables temporaires (visibles ou non) qu'il utilise ainsi que par défaut les tables résultat de vos requêtes (les célèbres tables REPONSE ou ANSWER). L'alias :PRIV: est attaché à une session Paradox et deux personnes ne peuvent travailler simultanément avec le même répertoire privé (rien n'empêche, même si cela n'est pas forcément conseillé, de situer votre répertoire privé sur un serveur).

 

L'alias :WORK: (qui s'appelle :TRAVAIL: dans certaines versions) est le répertoire dans lequel Paradox va chercher par défaut vos objets si vous ne préciser pas de chemin (alias ou chemin complet). De même lorsque vous créer une fiche, un état, une table, une requête, Paradox va stocker cet objet par défaut dans l'alias :WORK:.

Bien sûr, vous pouvez forcer la localisation en indiquant le lieu de stockage (:alias:nom_table.db par exemple).

 

Lorsque vous lancer une session Paradox, vous avez automatiquement ces deux alias disponibles. Vous pouvez forcer leur localisation en modifiant la <link>ligne de commande de lancement de votre session. Vous pouvez également les modiifer dans Paradox (menu Fichier/ Répertoire de travail d'une part Outils/ Paramètres/ Préférences, onglet Base de données d'autre part).

 

:PRIV: et :WORK: sont deux alias que vous pouvez utiliser avec les règles suivantes:

- localisez dans :priv: toutes les tables et autres objets qui sont spécifiques au poste de travail. Ne stocker pas dans :priv: des objets (tables ou autres) que vous souhaitez pouvoir accéder d'un autre poste.

- localisez dans :work: tous les objets partagés entre plusieurs postes. Eviter de stocker dans :work: une table Reponse

d'une requête puisque chaque fois que quelqu'un va exécuter celle-ci votre table va être écrasée.

 

Pour :PRIV: nons appliquons la règle suivante:

- l'alias PRIV ne contient que des objets qui peuvent disparaître à la fin de la session. Une bonne façon de vérifier est de supprimer physiquement le répertoire associé (faites une sauvegarde avant si vos avez des doutes sur le contenu de votre répertoire privé) et de le recréer. Votre application doit continuer à fonctionner normalement.

 

Pour :WORK: nous appliquons la règle suivante:

- l'alias WORK ne contient que des objets permanents partagés par l'ensemble des utilisateurs. On y trouve au moins ceux nécessaires au démarrage de l'application (script ou fiche de démarrage).

 

Critères de répartition des objets dans les alias:

 

Critère 1 - Données /programmes:

 

Tout d'abord, nous séparons les données (tables, fichiers d'importation, fichiers d'esportation), des programmes (fiches, états, librairies, requêtes, scripts). Pour cela, quatre raisons:

1) La mise à jour du logiciel: le développement et la maintenance d'une application se fait souvent (devrait toujours se faire) dans un environnement distinct. L'intégration d'une nouvelle version de programmes peut ainsi se faire globalement en recopiant l'ensemble du répertoire.

2) La partie traitement peut être mis dans un répertoire en lecture seule sur le serveur, ce qui évite tout risque de modification intempestive du code (outre que vous pouvez également utilisez le mode distribué)

3) La sauvegarde journalière peut être limitée aux données (quoique ce n'est pas forcément la partie programmes qui prenne le plus de place)

4) Vous pouvez recopier en local vos répertoires programmes afin de diminuer la charge réseau (la version serveur sert de référence, mais l'alias pointe sur un répertoire local correspondant à une copie).

 

Critère 2 - Informations temporaires / Informations permanentes:

 

Les informations temporaires sont celles dont le contenu n'a de sens que dans le traitement en cours. Le cas type est celui d'une table Réponse résultat d'une requête et utilisée pour l'impression d'un état. Dès que celui-ci est imprimé, la table n'a plus dintérêt et peut être écrasée (ou supprimée). Sauf cas exceptionnel, les informatons temporaires sont en général également

privées (cf critère 3). Les données temporaires ne seront pas sauvegardées.

 

Les informations permanentessont celles qu'il est nécessaire de conserver dans le temps.

Les informations permanentes (données ou programmes, spécifiques à l'utilisateur ou non) devront faire l'objet d'une sauvegarde.

 

Critère 3 - Informations privées / partagées

 

Par privées, nous entendons les informations spécifiques à l'utilisateur. Il peut s'agir de données temporaires (tables réponses par exemple) mais également d'informations permanentes. Par exemple, un utilisateur peut vouloir conserver ses propres requêtes et/ou le résultat de celles-ci. Celles-ci devront être situées dans un répertoire privé, mais conservé en permanence (et sauvegardé).

 

Les informations partagées sont celles accessibles (en général simultanément) par plusieurs utilisateurs. Elles seront bein évidemment toujours localisées sur un serveur.

 

Critère 4 - Informations statiques / dynamiques

 

Nous utilisons le terme statique pour caractériser les informations non modifiables et le terme dynamique dans le cas contraire. Par exemple:

- les programmes d'une application seront localisés dans un alias statique (on ne modifie pas le programme sauf pour des mises à jour de version)

- les requêtes d'un utilisateur seront localisées dans un alias dynamique

- les tables de référence provenant d'une autre application seront dans un alias statique (on ne peut les modifier)

- les tables permanentes d'une application seront dans un alias dynamique.

 

Critère 5 - Informations applicatives / communes

 

 

Dans le cas où vous avez plusieurs applications sur votre site, vous pouvez avoir desinformations communes qui sont par exemple des programmes utilitaires, des tables générales (table des codes postaux par exemple). Il est bien sûr inutile de dupliquer ces tables (et les programmes qui les gèrent) dans toutes vos applications. On utilisera un alias (il est conseillé d'utiliser le même dans toutes vos applications mais ce n'est pas une nécessité: ce qui est nécessaire c'est qu'ils pointent tous au même endroit) distinct pour ce type d'information.

 

Critère 6 - Informations techniques / applicatives :

 

Il est souvent utiliser dans une application des mécanismes généraux (les mêmes quelle que soit l'application) qui permettent de paramétrer le fonctionnement de celle-ci. Par exemple, on a une table permettant de gérer les champs en incréments, une table pour les utilisateurs ... . La séparation dans des alias différents des informations de nature techniques (on appelle ce qui reste les informations applicatives) facilitera souvent la maintenance.

 

Liste des alias résultant des critères:

 

Dans les noms d'alias ci-après, par convention la première lettre sera A s'il s'agit d'un alias contenant des informations applicatives, ceci afin d'avoir les alias applicatifs en premier dans les listes.

 

La prise en compte de l'ensemble de ces critères conduit à créer les alias suivants:

 

Alias locaux:

 

Les alias locaux sont situés soit sur le poste de l'utilisateur, soit sur le serveur mais dans un répertoire propre à l'utilisateur

 

:APRIVE:

Cet alias correspond en fait à l'alias PRIV de Paradox mais permet d'éviter de perturber l'utilisateur si celui-ci utilise parallèllement

Paradox interactif. L'alias APRIVE comprend toutes les informations (tables et programmes) temporaires.

 

:ALOCAL:

Cet alias comprend les informations privées permanentes. Cet alias existe essentiellement pour les utilisateurs travaillant en paradox interactif. Dans ce cas, il est souvent préféré de laisser à l'utilisateur la gestion complète de cet alias.

 

:ADL:

Il s'agit d'un alias comprenant des tables temporaires mais dont la structure est conservée de façon permanente. Le cas typique est celui des tables maîtres des états , dont le contenu résulte d'une requête. Il est cependant utile de conserver la strucutre de la table pour pouvoir modifier la maquette de l'état (on évite de coqsntruire des tables directement sur une table réponse car on risque en maintenance de modifier intempestivement la structure des états). Le serveur contient un répertoire ADL qui est recopié en local à l'installation du logiciel.

 

:-TDL:

Idem ADL pour les données techniques.

 

Alias serveurs

 

Comme leur nom l'indique, ces alias sont situés sur le serveur et correspondent aux informations partagées.

 

:AD:

contient les données applicatives dynamiques. Le répertoire associé est à sauvegarder systématiquement.

 

:ADS:

contient les données applicatives statiques. Le répertoire associé n'est à sauvegarder qe lorsqu'il y a eu des modifications. Le répertoire doit cependant être en lecture/écriture, Paradox écrivant un fichier paradox.lck dans chaquerépertoire comprenant

des tables.

 

:AP:

Contient les programmes de l'application. Ce répertoire peut être déclarée en lecture seule pour tous les utilisateurs de l'application.

 

:ADC:

contient les données utilisées par plusieurs applications. Le répertoire associé est à sauvegarder systématiquement.

 

:ADCS:

Idem ADS mais pour les données communes.

 

:APC:

contient les programmes communs à plusieurs applications.

 

:TD:

contient les données techniques dynamiques. Le répertoire associé est à sauvegarder systématiquement.

 

:TDS:

Idem ADS mais pour les données techniques. On notera que cet alias contiendra souvent les tables de paramétrage du logiciel (libellés des messages d'erreur par exemple). Le contenu de l'alias TDS est gérée totalement par le développeut tandis que l'alias TD contient des tables dont le contenu peut être mis à jour continuellement (table des utilisteurs par exemple).

 

:TP:

idem AP mais pour les programmes utilitaires.

 

:TDC:

Idem ADC mais pour les données techniques.

 

:TDCS:

Idem ADCS mais pour les données techniques.

 

:TPS:

idem AP mais pour les programmes utilitaires commmun à plusieurs applications. En général les alias TP et TPS sont confondus (par nature même des programmes utilitaires).

 

On peut avoir plusieurs alias réels d'un type donné, par exemple, si on veut gérer par module, si on veut isoler les données de type historique, .les données d'importation, d'exportation, .. . On pourra les appeler par exemple AD_mod1, AD_mod2, AD_HIST, etc... Même chose pour les alias AP.

 

Un peu moins d'alias:

 

Nous arrivons avec le raisonnement ci-desus à 14 alias, et on peut facilement affiner des critères (par exemple les données techniques locales, par exemple) ou ajouter de nouvelles règles: par exemple beaucoup de personnes font une répartition des prgrammes dans des alias déclinés par nature de programme: fiche,

requête.

 

Tous ces alias sont-ils vraiment utiles?

 

Il est peu probable que votre application nécessite l'ensemble de ceux-ci. Nous utilisons deux règles de simplification évidente:

 

- Nous ne définissons pas d'alias qui ne servent à rien. Par exemple nous n'avons que très rarement les alias ALOCAL et TDL. Idem pour TDC et TDCS.

 

- Nous fusionnons les alias qui peuvent l'être: si vous n'avez qu'une table dans ADS, il est certainement plus simple de la localiser dans le répertoire AD (la principale différence étant qu'elle fera l'objet

d'une sauvegarde systématique ce qui n'est pas forcément un drame).

 

De même ADC et ADCS sont souvent fusionnés. La limite de la fusion est de garder la séparation entre Local et Serveur d'une part (obligatoire), programmes et données d'autre part (fortement conseillée).

 

La configruation minimale conseillée:

 

Comme alias local: ADL (aprive = priv ;ou fusion de aprive et adl)

Comme alias serveur: AD, AP, TD, TDS, TP.