Discussion :

[poissonsoluble]

En parcourant les pages du débat http://www.developpez.net/forums/showthread.php?t=1013, j' n'arrive pas encore à me décider ou plutôt convaincre à migrer ma base access vers SQL Server?
Je dispose actuellement d'environ 100 tables et 90 requetes sous access avec une application ecrite en VB6. les utilisateurs demmandent encore des requetes à créer (une 20aine) et des fonctionnalités à rajouter qui demanderont la création de d'autres tables. Je suis entrain de faire un peu de nettoyage dans cette bdd car c'est une chaîne de stagiaire qui ont crée l'application et la bdd avec
Je sais que la migration me demandra de refaire les 90 requetes!!
Avec access, les utilisateurs se plaignent de la limitation d'utilisation simultanée de l'application!!
Merci pour votre contribution!

[=JBO=]

copie de la réponse de cbleas
http://www.developpez.net/forums/sho...39#post2039539

Bonjour,

pour ma part j'ai fait une application qui fonctionne soit sous ACCESS soit sous SQL server. La migration de 400 tables 400 requètes a pris un certain temps mais cela vaut la peine non pas pour dire qu'ACCESS est moins bon que SQL server mais pour pouvoir contenté tout le monde.

Si tu as 100 tables avec peux de données il est possible d'utiliser ACCESS maintenant si le nombre de données dans les tables sont importantes là pas de doute il faut utiliser SQL server (si en réseau). si monoposte autant utiliser ACCESS.

Maintenant je trouve SQL server plus stable mais peut etre que je me plante.
Par contre ACCESS est sans conteste plus facile à installer.
Pour la programmation des tables et requètes avec SQL server Express c'est aussi simple sur l'un que sur l'autre.

En un mot les deux sont bien il suffit de prendre celui qui correspond le mieux à votre besoin.
Bonne journée

[=JBO=]

j' n'arrive pas encore à me décider ou plutôt convaincre à migrer ma base access vers SQL Server?
Je dispose actuellement d'environ 100 tables et 90 requetes sous access avec une application ecrite en VB6.
[...]
Je sais que la migration me demandra de refaire les 90 requetes!! !

Non, il n'est pas obligatoire de "porter" les requêtes dans ton serveur SQL.
C'est juste une question d'architecture et d'efficacité.

Dans un premier temps l'architecture de l'application pourrait évoluer ainsi:

(1) l'application VB6 travaille toujours sur un fichier MDB.
(2) dans le fichier MDB:
* toutes les tables sont des tables attachées vers un serveur SQL,
* les requêtes "travaillent" à partir des tables attachées.
(3) il est préférable que le fichier MDB devienne un "composant" de l'application VB6 et ne soit pas partagé par tous les utilisateurs.

Donc, pour ton application VB6, la migration est quasi-transparente et ne nécessite pas de modification.

Un petit bémol...

Evidemment, si le volume de données est conséquent, il est possible que l'exécution des requêtes ne soit pas toujours optimisée.

Néanmoins c'est une possibilité de migration à moindre coût, ne serait-ce que dans le cadre d'un prototype.
_

[poissonsoluble]

J'ai 2/3 questions à poser la dessus :
- Pour les requetes stockées côté Access, il n'y aura aucune modifications à faire?
- Comment est ce que le fichier mdb soit un composant de l'appli? Je ne comprend pas trop ce que vous voulez dire ni comment le faire
- En suivant ce chemin, est ce que c'est possible de créer les nouvelles requêtes que je dois faire côté sql Server, comme ca s'ils se décident de migrer un jours vers sql server y aura une partie des requêtes à ne pas refaire

Pour le volume des données, je ne sais pas encore, car je travaille sur une bdd de test donc il faut que je demande au supérieur!!
Voilà, je vous remercie de votre aide à l'avance. Bonne journée

[=JBO=]

- Pour les requetes stockées côté Access, il n'y aura aucune modifications à faire ?

Aucune modification n'est nécessaire.
Il suffit que les tables attachées aient le même nom et la même structure que les tables qui étaient hébergées dans le fichier MDB.
Alors pour les requêtes Access ce sera complètement transparent.

- Comment est ce que le fichier mdb soit un composant de l'appli? Je ne comprend pas trop ce que vous voulez dire ni comment le faire.

Concrêtement, l'application VB6 est placée dans un dossier sur le PC de l'utilisateur n'est-ce pas ?
Eh bien, le fichier MDB (qui va servir de "pont" vers le serveur SQL) sera alors placé dans le même dossier.
Ainsi, l'application VB6 accèdera directement au fichier MDB placé dans le même dossier.
C'est pour ça que je l'ai qualifié de "composant", tout simplement parce qu'il fait partie de l'application et n'a pas vocation à être partagé entre les différents utilisateurs.

- En suivant ce chemin, est ce que c'est possible de créer les nouvelles requêtes que je dois faire côté sql Server, comme ca s'ils se décident de migrer un jours vers sql server y aura une partie des requêtes à ne pas refaire

Oui bien sûr.

Côté SQL Server tu vas créer des vues ou des procédures stockées qui retourneront des enregistrements.
Une vue SQL Server peut être attachée comme si c'était une table.

-=-=-=-=-=-=-=-=--==-

Mais, là non plus, ce n'est pas obligatoire. Access offre une alternative.
les requêtes SQL Direct.

Il s'agit d'un type de requête particulier, contenue dans le fichier MDB.

Une requête SQL Direct contient le code SQL qui sera envoyé au Serveur SQL et sur lequel il sera exécuté, de façon à optimiser les performances.
C'est un excellent compromis, puisque tu n'as qu'à migrer les données.
_

[poissonsoluble]

En quoi cette solution sera mieux que l'état actuel de l'appli? Au niveau performance et optimisation de réponses aux requêtes envoyés. Merci

[=JBO=]

Avec access, les utilisateurs se plaignent de la limitation d'utilisation simultanée de l'application!!

Alors ce ne serait pas plutôt soit un Pb de conception, soit une méconnaissance de l'accès mutli-utilisateurs sur une BD Access ?

De quoi se plaignent-ils au juste ?

Ce peut être une piste d'amélioration pas trop compliquée !
Il faudrait juste revoir l'accès concurrent aux données !
_

[poissonsoluble]

Leur bdd est un bordel pas possible, j'ai proposé de refaire la conception de la bdd mais cela me prendrai une durée non négligeable, et je n'aurai pas le temps de refaire toute l'appli car ils sont pressé d'avoir de nouvelles fonctionnalités (formulaires, requetes...) Je peux corriger qq erreur dans la bdd mais pas tout, les modif à apporter à l'appli est conséquent et ils ne veulent pas s'aventurer la dessus actuellement. Moi, ça me fait ch... de laisser tel quel donc, j'essaye de monter un document pour argumenter mon point de vue qui est de refaire la conception de la bdd en premier puis soit de migrer maint ou plutard mais que les choses soient bien faite d'une manière à faciliter la migration vers SQL Server

[=JBO=]

Avec access, les utilisateurs se plaignent de la limitation d'utilisation simultanée de l'application!!

Alors ce ne serait pas plutôt soit un Pb de conception, soit une méconnaissance de l'accès mutli-utilisateurs sur une BD Access ?

De quoi se plaignent-ils au juste ?

Ce peut être une piste d'amélioration pas trop compliquée !
Il faudrait juste revoir l'accès concurrent aux données !

Ta réponse...

Leur bdd est un bordel pas possible, j'ai proposé de refaire la conception de la bdd mais cela me prendrai une durée non négligeable, et je n'aurai pas le temps de refaire toute l'appli car ils sont pressé d'avoir de nouvelles fonctionnalités (formulaires, requetes...) Je peux corriger qq erreur dans la bdd mais pas tout, les modif à apporter à l'appli est conséquent et ils ne veulent pas s'aventurer la dessus actuellement. Moi, ça me fait ch... de laisser tel quel donc, j'essaye de monter un document pour argumenter mon point de vue qui est de refaire la conception de la bdd en premier puis soit de migrer maint ou plutard mais que les choses soient bien faite d'une manière à faciliter la migration vers SQL Server

Excuse moi mais, si ta réponse explique l'enjeu, en revanche elle ne relate pas ce qui est la cause du mécontentement des utilisateurs.

Et je crois qu'il est IMPORTANT de CARACTERISER les situations dans lesquelles les utilisateurs ont un Pb de <<limitation d'utilisation simultanée>>.

Ton document ne sera pertinent que dans la mesure où tu montres d'abord la nature de la gêne aux utilisateurs.
Ce préalable est indispensable pour ensuite appréhender l'ensemble des "mesures correctives" à leur disposition.
_

[poissonsoluble]

Alors ce ne serait pas plutôt soit un Pb de conception, soit une méconnaissance de l'accès mutli-utilisateurs sur une BD Access ?

De quoi se plaignent-ils au juste ?

Ce peut être une piste d'amélioration pas trop compliquée !
Il faudrait juste revoir l'accès concurrent aux données !
_

Ou est ce que je peux vérifier la manière que c'est géré l'accès concurrent aux données? C'est peut être bete comme question mais merci à l'avance

[=JBO=]

Ou est ce que je peux vérifier la manière que c'est géré l'accès concurrent aux données?

Déjà, intuitivement, tu vois bien que les Pb d'accès concurrents se posent au moment de la modification/suppression des données, éventuellement à l'ajout de données.
Ça peut aussi arriver lors de l'exécution de requêtes UPDATE ou DELETE.

Franchement, fais une enquête auprès de 2 ou 3 utilisateurs qui te montreront les écrans où des Pb surviennent.
_

[poissonsoluble]

Je voulais simplement remercier ceux qui ont contribué dans ce sujet La décision a été qu'il 'y aura pas de migration vers SQL Server, car ils ont décidé ainsi!! Voilà c'est tout! Bonne contiuation à tous

[meandreux]

bonjour,

pour reprendre cette discussion, contrairement à PoissonSoluble, on m'impose de migrer une base ACCESS vers sql Server.

J'ai décortiqué la documentation riche et complète de Jean Philippe Ambrosino :


http://argyronet.developpez.com/office/access/mdb2adp/

Le problème est que je n'ai que des notions superficielles et éloignées en ACCESS.

Mes questions portent sur les requêtes :


Question 1 : il s'agit d'une question basale et générale ACCESS : les requêtes ont-elles pour seul but d'être utilisées dans les formulaires et les états ?

Question 2 :
j'ai compris qu'il fallait que je transforme mes requêtes ACCESS en vues SQL (voire en procédure stockée). Mais comment les implémenter ensuite ?


Merci d'avance pour vos réponses qui j'espère seront éclairées