Discussion :

[Robert1957]

Bonjour,

Je dois migrer une base Access, qui est devenu trop volumineuse, sur un serveur SQL. J'ai déjà fait en liant les tables de la frontale directement sur le serveur (est-ce qu'on peut faire mieux, ex. connexion ADO). Mais mon questionnement est quels sont les pièges à éviter et comme le titre le dit quelles sont meilleures pratiques pour faire fonctionner une application Access/SQL server.

Bonne journée

[marot_r]

Bonjour.

Tu voudras peut-être lire cela :
When and How to Upsize Microsoft Access Databases to SQL Server
http://www.fmsinc.com/microsoftacces.../how/index.htm
qui semble très bien fait.

Sinon attention les boolean n'existent pas en SQL Server.
De mémoire ce sont des type Bit et ils vallent 0 pour faux et 1 pour vrai (en Access vrai=-1).
Si tu as utilisé les constantes figuratives True et False, tu ne devrais pas avoir de surprise.
Par contre si tu as testé (ou utilisé) les valeurs directement, tu risques des problèmes.

Les champs Mémo n'existent pas non plus et leur équivalent (VarChar de mémoire) sont aussi plus courts que ceux d'Access.
Il y a aussi des trucs à surveiller sur les nombres dont les minimums et maximums sont plus élevés dans SQL Server.

Ici un article à propos des dates :
Understanding problems when converting Access time data to SQL Server
http://www.ascassociates.biz/underst...to-sql-server/

Il y a aussi un livre consacré à ce sujet :
From Access to SQL Server
http://www.booksamillion.com/p/From-.../9781893115248
Désolé pas d'info sur la qualité de l'ouvrage et il date de l'an 2000 mais tu pouras peut-être le trouver dans une bibliothèque publique.

Je l'ai trouvé avec Google Book ici :
https://books.google.ca/books?id=gcE...gotcha&f=false

Ici aussi quelque chose qui paraît utile.
https://blogs.office.com/en-us/2012/...to-sql-server/

ausi :
Linking Access applications to SQL Server - Azure SQL DB (AccessToSQL)
https://docs.microsoft.com/en-us/sql...db-accesstosql

Ce n'est peut-être pas exactement la réponse que tu attendais pour "Meilleures pratiques" mais je pense que c'est important quand même.

A+

[Robert1957]

Bonjour marot_r,

Merci pour cette réponse. J'avais déjà consulté ton premier lien: http://www.fmsinc.com/microsoftacces.../how/index.htm. Pour ce qui est des vrai/faux en effet si on regarde la table avec SQL Server Management Studio les chiffres sont 0 et 1 mais curieusement il semble qu'Access les interprètes lorsqu'on attache les tables à notre application parce que dans mes tables attachées je retrouve 0 et -1. Cependant il faut aller ajouter un "Default Value or Binding" = 0 parce qu'il n'est pas possible de mettre une valeur Null ce qui est dérangeant lors de la saisie de données.

Pour les dates SQL est plus difficile qu'Access, une date non valide ex: 1111/11/11 va annuler une transaction.

Je n'ai pas lu le livre, j'ai regardé ton lien et ça semble prometteur en effet, je regarde ça.

Pour ce qui est de la doc de Microsoft, j'avais déjà lu. C'est technique mais ça ne donne pas vraiment de "in" à savoir c'est mieux de fonctionner ainsi plutôt que comme cela.

Avec des tables attachées on peut toujours se servir de DAO mais mon questionnement est : Est-ce qu'on exploite SQL de la manière la plus efficace. J'ai fait certaines lectures et il semble que SQL ne renvoit pas toutes les données donc économie sur le réseau. La raison de la migration est que les tables de mon application sont rendues avec plus ou moins 3 000 000 de lignes et qui plus est il y a maintenant environ 30 utilisateurs ce qui est beaucoup et ralenti l'application(surtout les utilisateurs, parce que le week-end ça va encore bien). Donc pas vraiment le choix.

Je continue à regarder, et encore une fois merci.

[marot_r]

Bonjour.

De ce que je sais quand tu utilises des tables attachées c'est Access qui fait tout le travail donc tu as la puissance de ton poste client.
Le serveur de BD se contente de t'envoyer les données que tu demandes.

Si tu veux un vrai gain de puissance, il va falloir déléguer au serveur de BD et donc utiliser des procédures stockées et des requêtes écrites sur la BD SQL Server pour la BD SQL Server.

Si tu le souhaites, tu peux utiliser le mode SQL direct qui te permet d'écrire dans Access du SQL "natif" de SQL Server.
Access ne garde alors que l'instruction SQL qu'il transmet pour exécution au serveur dédié.
Les gains sont parfois impressionnants. J'ai eu un cas où je suis passé d'une heure en Access à quelques minutes grâce à la puissance du serveur dédié.
Attention au problème de time out si tes requêtes ou tes traitements sont long. Il y a un au niveau de la requête et peut-être un au niveau du driver.
Et ces requêtes ne peuvent pas être utilisé partout où tu emploirais une requête Access donc faire des essais avant de se lancer.
Bien sur tu peux tout mettre sur le serveur dédié mais cela peut prendre pas mal de temps aussi je te conseille d'y aller par étape : tu repères une requête ou un traitement problématique et tu améliore ce point.

Sinon, je ne pense pas qu'utiliser ADO soit plus ou moins efficace que d'utiliser DAO.
En tout cas je n'ai jamais croisé cette information nul part.

Avant il y avait un mode projet qui mettait tout sauf l'interface utilisateur dans SQL serveur mais il a été abandonné par M$.

A+