Les connexions ODBC permettent à BiBOARD d’accéder à différentes sources de données : bases SQL, fichiers ou dépôts de données.
Une bonne organisation des connexions facilite :
- la maintenance,
- les migrations,
- la lisibilité des projets,
- et la sécurisation des environnements.
Définition : connexion ODBC #
Une connexion ODBC centralise les paramètres d’accès à une source de données :
- serveur,
- base de données,
- dépôt de fichiers,
- identifiants,
- droits d’accès.
Elle peut ensuite être réutilisée dans les objets BiBOARD :
- requêtes.
Bonnes pratiques #
Utiliser un nommage métier et lisible #
Le nom d’une connexion doit permettre d’identifier rapidement :
- la source,
- l’environnement,
- et éventuellement l’usage.
Le préfixe ODBC_ est généralement inutile, car l’objet est déjà identifié comme une connexion ODBC dans BiBOARD.
Recommandé #
ERP_PRODDWH_RECDEPOT_FACTURESFILE_EXPORTSSQL_SAGE_PROD
À éviter #
ODBC1Connexion_TESTSQL01TESTODBC_SQL_SERVER_01
Un bon nommage doit rester :
- simple,
- stable,
- compréhensible par l’équipe.
Distinguer les environnements #
Créer des connexions distinctes pour :
- le développement,
- la recette,
- la production.
Exemple #
ERP_DEVERP_RECERP_PROD
Cela permet :
- de limiter les erreurs,
- de sécuriser les tests,
- et de simplifier les migrations.
Connexions ODBC fichiers #
Les connexions ODBC fichiers possèdent une particularité importante :
Une connexion est liée à un répertoire de dépôt précis.
Ainsi :
- un changement de dépôt,
- un nouveau partage réseau,
- ou un nouvel emplacement de fichiers,
nécessite généralement une nouvelle connexion ODBC.
Exemple #
Une connexion :
FILE_FACTURES
pointant vers :
\\SERVEUR\Depot\Factures
ne pourra pas être réutilisée directement pour :
\\SERVEUR\Depot\Commandes
Une nouvelle connexion devra être créée.
Utiliser des chemins stables #
Privilégier :
- les chemins réseau partagés,
- les répertoires dédiés,
- les conventions homogènes.
Recommandé #
\\SERVEUR\DepotBiBOARD\Exports
À éviter #
C:\Users\Paul\Desktop\Exports- lecteurs réseau personnels (
Z:\Exports)
Les chemins locaux ou utilisateurs :
- compliquent les migrations,
- dépendent du poste utilisateur,
- et peuvent provoquer des erreurs d’exécution sur les serveurs BiBOARD.
Mutualiser les connexions avec cohérence #
Une connexion peut être partagée si :
- la source est identique,
- les droits sont identiques,
- le dépôt est identique,
- et l’usage reste cohérent.
À l’inverse, il est préférable de créer une connexion dédiée lorsque :
- les droits diffèrent,
- les environnements diffèrent,
- les dépôts diffèrent,
- ou les usages deviennent trop spécifiques.
Erreurs fréquentes #
| Mauvaise pratique | Risque |
|---|---|
| Utiliser un chemin local utilisateur | Fonctionne uniquement sur le poste du créateur |
| Réutiliser une connexion fichier pour plusieurs dépôts | Maintenance complexe et risques d’erreur |
| Utiliser une connexion de production en développement | Risque de modification réelle des données |
| Utiliser des noms techniques ou génériques | Difficulté de maintenance |
| Multiplier les connexions sans convention | Architecture difficile à maintenir |
Recommandations générales #
Une connexion ODBC doit être :
- clairement identifiable,
- stable dans le temps,
- liée à un usage cohérent,
- et facilement maintenable.
Une bonne organisation des connexions simplifie :
- les évolutions,
- les migrations,
- le support,
- et la compréhension globale du projet BiBOARD.
