Discussion :

[P Vidal]

Bonjour.
La haute tenue de ce forum m'incite à poser une question, perso mais qui doit se poser à d'autres membres:
J'ai développé un site pour une asso d'achat direct aux producteurs paysans.
Sur le site il y a une BDD Access monofichier .mdb qui enregistre les mouvements des associés, accédée en ADOX/ASPX.

Sur l'ordin de l'association il y a une BDD Acces mdb monofichier, mise à jour tous les deux jours à partir de celle du site, et contenant des forms avec des programmes en VBA, longs en exécution tous les 2 jrs (beaucoup de requetes).

Les tables de la BDD locale sont appelées à grossir, je voudrais donc migrer vers SQL Server. Mais je n'ai pas le temps de convertir le DAO en ADOX pour faire un projet ADP.

Question 1: est ce qu'en cas ainsi de tables SQL attachées à une Bdd Access (Bdd Frontale/Principale, ou simple attachement de tables) sur un même ordinateur, les transferts entre SQL et ACCESS pénalisent beaucoup l'exécution ?. (Ajouter de la RAM ?). Y aurait il un réel avantage à passer à un projet client/serveur ?.
Est ce que je ne risque pas d'avoir une exécution encore plus longue ?.

Question 2. Pour fiabiliser la bdd du site je vais la migrer vers SQL. Mais pour y accéder tous les deux jours pour en extraire les modifs et les mouvements sans devoir stopper l'exploitation, je pense la convertir en projet ADP: les transferts de table ne sont pas un problème mais je pense que le système de tables attachées n'assurait pas la sécurité de l'accés ?. OK ?.

Je n'ai pas assez de connaissance du dessous le capot. Pourriez vous me donner un avis, afin de m'éviter de me fourvoyer.
Mille mercis d'avance.
Pierre

[Zabriskir]

Bonjour,

Question 1 :
Oui, travailler avec des tables liées/attachées ne permet pas de gagner en performances.

Question 2 :
Je ne comprends pas bien ce que vous voulez faire.
Comment faites-vous le transfert de données actuellement ?
Quelle taille fait votre base de données locale ? et la base du site ?

@+

[SQLpro]

Lisez ce que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p6...er-le-piege-a/

A +

[P Vidal]

Grand merci à tous les deux pour votre réponse. C'est super et inespéré.

je précise: SQL permet plus d'accès simultanés avec moins de charge de transfert entre le client et le serveur,
Il permet aussi de plus grands volumes de données, et accessoirement de la sécurité et des sauvegardes sans stop de l'exploitation.

Je pense donc migrer la base .mdb qui est sur le site, vers une base 100% SQL pour ces trois raisons à la fois.
(Même si je me demande comment fonctionne le Client/Serveur Bdd sur un serveur internet fonctionnant en ASP: Je pense que les sessions ASP
ouvertes sur le serveur internet par les internautes jouent le role du client distant en non internet, car l'internaute n'est pas le client de la BDD, puisque c'est le serveur internet (IIS) qui exécute les pages ASP et consulte la base pour préparer les pages HTML.
Donc les transferts de données entre la session internet cliente et la BDD se font sur le même ordinateur, ce qui est moins pénalisant qu'en passant par un réseau local... Je dis peut être des bétises...)

Donc pas d'état d'ame pour migrer la base du site vers SQL.(d'autant plus qu'elle ne contient pas de VBA, elle est accédée en ADOX)

Actuellement la base de donnée qui est sur l'ordin de l'association est mise à jour par import des tables de celle du site, laquelle est rapatriée pour celà par FTP. Elle n'est à ce jour pas trés grosse car en fait le site n'a pas encore démarré en réel.
Mais vu les infos stockées dedans, elle devrait - si çà marche - être vite volumineuse.

L'incertitude est surtout pour la migration de la BDD locale, de l'ordin de l'association:

J'avais déjà lu l'article de Frédéric BROUARD qui éclaire trés bien sur les problèmes de tables attachées.

Mais il y a beaucoup de code en VBA DAO dedans, je bosse depuis longtemps là dessus et je ne me vois pas maintenant repartir dans une refonte des programmes vers ADOX. Donc je pense qu'il m'est dans ces conditions interdit de migrer vers une BDD 100 % SQL.

Or cette BD locale deviendra volumineuse aussi

Reste que les tables attachées malheureusement je pense (???).

La question est: du fait que cette BDD locale n'est utilisée que par un client unique (car le gros du travail est dans l'exécution de programmes VBA sur le même ordin), et non dans des saisies de mouvements ou interrogations de la BDD), et sur un ordinateur unique (pas de réseau), est ce qu'il y aura
quand même des transferts pénalisants entre la BDD SQL locale contenant les tables attachées, et la BDD Access à laquelle elles sont attachées, les deux se trouvant sur le même ordinateur, et il ne peut pas y avoir de requêtes simultanées.
C A D est que çà va être encore plus long que quand tout est dans une unique BDD Access fichier ?.

Merci de vous être interressé à ma question.

Cordialement.

P Vidal

[StringBuilder]

J'ai pas tout compris, mais en gros :

- SQL est un langage. Merci de parler de SQL Server (s'il s'agit du SGBDR de Microsoft ou de MySQL par exemple) plutôt que de SQL en désignant l'outils.

Niveau migration d'Access vers SQL Server, ça se fait en 3 clics depuis l'interface d'administration de SQL Server : importer tables > sélection du fichier access, tout sélectionner et roule ma poule.

Niveau programmation, ça ne devrait pour ainsi dire rien changer : les pages ASPX qui accèdent à la base Access le font à l'aide d'un object connection, et utilisent des requêtes SQL pour interroger la base.

=> Il faut changer le type des différents objets de connexion/interrogation de la base, puis vérifier que les requêtes SQL sont bien compatibles. Mais en gros, c'est chercher/remplacer , trois clics, et quelques caractères incongrus à virer des requêtes SQL. Ca se fait normalement sans douleur.

Enfin, l'utilisation d'Access comme front-end pour interroger une base SQL Server distante, perso je ne trouve pas que ce soit une mauvaise solution.

Les performances ne seront pas forcément super, mais comme tu le dit, c'est principalement de la consultation par une personne : les perfs on s'en moque donc un peu.