---
title: ODBC
description: "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…"
url: "https://wiki.biboard.fr/wiki/bonnes-pratiques-odbc/"
updated: "2026-05-19"
category: Bonnes pratiques
---

# ODBC

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_PROD`
- `DWH_REC`
- `DEPOT_FACTURES`
- `FILE_EXPORTS`
- `SQL_SAGE_PROD`

### À éviter

- `ODBC1`
- `Connexion_TEST`
- `SQL01`
- `TEST`
- `ODBC_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_DEV`
- `ERP_REC`
- `ERP_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 :

- `\SERVEURDepotFactures`

ne pourra pas être réutilisée directement pour :

- `\SERVEURDepotCommandes`

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é

- `\SERVEURDepotBiBOARDExports`

### À éviter

- `C:UsersPaulDesktopExports`
- 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.