Migration access vers MSSQL

[guidav]

Bonjour

Notre système d'information est actuellement sous Access 2000. Les tables sont devenues énormes, trop nombreuses, bref, ingérables.
Mon équipe a pour projet de migrer les tables historiques vers MSSQL, de sorte à continuer à faire les traitements sous Access, mais sur des tables attachées en ODBC.
Le problème pour cette migration est qu'il est indispensable d'avoir une clé primaire pour manipuler les données d'une table attachée.
Or la quasi-totalité de nos tables n'en disposent pas, et ont des champs à valeur NULL là où devraient se trouver les clés.
Ma question est donc : que me conseillez-vous de faire ? J'ai déjà quelques solutions :
- remplacer tous les NULL par des "" et autoriser les chaînes vides
- remplacer les NULL par "#NC# ou autre formule cabalistique (n'oublions pas qu'access ne fait pas de différence visuelle entre NULL et "")
- ajouter un autoincrement comme clé primaire par table, et perdre la possibilité ultérieure de faire de l'intégrité sur les clés

Ensuite, concernant la définition des tables, faut-il mieux :
- insérer systématiquement la valeur "" et ne pas définir de valeur par défaut dans les tables
- ou laisser le SGBD gérer la valeur par défaut, et n'insérer que les dans champs contenant de l'information "utile" ?

Merci de vos avis

Bonsoir,

Tu pourrais pallier à l'odbc en changeant le format du fichier Access.
Au lieu d'avoir un mdb, il te faudrait le paramétrer en adp (projet Access).
Ainsi, adieu odbc et les clé qui sont nécessaires.
Enfin, cela tout dépend du serveur Sql que tu as, ainsi que de la version d'Access, il faut qu'elles soient compatibles.
Un projet Access (Adp) "voit" toutes les tables à partir du moment où il est bien paramétré sur le serveur que tu veux exploiter.

A mon avis, oriente toi un peu sur le forum Access et ses spécialistes, ils te feront avancer.

[guidav]

Merci pour l'idée, mais ça ne correspond pas vraiment à mes besoins, car nous avons besoin de continuer à faire nos traitements tels qu'ils sont, c'est juste que les tables d'historiques sont devenues trop grosses pour access.

[Antoun]

Les solutions "" et autres libellés non naturels du genre "#NC#" sont à bannir. Le NULL est là pour représenter de la meilleure manière possible l'absence d'information.
Du coup, les clés auto-incrémentées me semblent effectivement la meilleure solution.
Concernant la définition des tables, il faut interdire systématiquement la chaîne vide afin d'avoir des NULL propres. Pour les insertions, laisser effectivement le SGBD utiliser ses valeurs par défaut, afin d'avoir une cohérence entre les différents traitements.

[SQLpro]

Sans clef une table se lit comme un fichier et perd à la fois tous sens BD ainsi que toute performances...

Posez vous la question de savoir s'il est intéressant de conserver des informations que vous ne pouvez pas retrouver et qui pénaliseront les traitements.

A +