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

[argyronet]

Bonjour,

Quelques arguments peuvent t'apporter une réponse dans ce tuto...

Argy

[=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=]

argyronet, j'ai l'impression que tu as raté le "début du film".

Ici il s'agit d'une application VB6/???/MDB/JET.
Avec VB6 il n'est pas question de migrer vers une solution ADP (qui est le sujet de ton tutoriel), car ADP c'est de l'Access !
(je sais que tu le sais, mais je l'écris pour ceux qui ne savent pas ! )

Quelques arguments peuvent t'apporter une réponse dans ce tuto...

Donc pour ne pas embrouiller poissonsoluble avec des informations certes intéressantes (ADP) mais non pertinentes au regard de sa question initiale, je lui recommande de lire en particulier certains passages de ton excellent tutoriel.

Le chapitre 4: Quel est l'avantage de SQL Server par rapport à une base Access ?

Les chapitres 5 à 8, pour l'aspect migration des données de MDB vers SQL Server, en notant bien que l'assistant de migration ne fonctionne qu'avec Access.

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

A ce stade de la discussion, il serait bon que poissonsoluble nous explique la méthode d'accès aux données utilisée dans l'application VB6.

En effet, la méthode d'accès aux données peut être un facteur limitant quant aux alternatives de migration théoriquement possibles.

Je m'explique à travers un exemple:
Supposons qu'une application VB6 accède aux données à travers des "contrôles d'accès aux données de VB6" (type DBList, DBCombo, DBGrid, DataList, DataCombo, DataGrid...).
L'utilisation de ces contrôles natifs de VB6 apporte certaines contraintes non négligeables et qu'il faut absolument connaître avant de faire un choix de migration.
En effet, il s'agit de garantir que l'application sera toujours opérationnelle après la migration.
Sinon, il faudra faire évoluer l'application pour l'adapter aux nouvelles conditions d'exploitation de la base de données migrée.
_

[=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.
_

[argyronet]

Merci JBO... Euh, si un peu quand même euh; Ah que j'ai suivi...
En fait, quand il a écrit :

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

je me suis dit que la lecture du paragraphe concernant le pourquoi de la migration serait convaincant... peut-être... Celui d'ailleurs que tu le soulignes, à savoir, le chapitre 4...

Urrrgh, ce doit être la fatique... Depuis 11 jours, il a poussé un chez moi et, enfin, voilà, quoi...

Argy

[=JBO=]

Depuis 11 jours, il a poussé un chez moi et, enfin, voilà, quoi...

Sincères félicitations

et beaucoup de bonheur aux heureux parents et à leur progéniture



_

Mais... qu'est-ce qu'on entend là bas ???



_



Et bon courage


P.S. A quand le tutoriel << changer la couche de bébé >> AVEC ACCESS bien sûr !
_

[Maxence HUBICHE]

Juste une petite remarque basée sur l'expérience ...
Le coup de l'attache de tables SQLServer dans une base access via ODBC peut poser des problèmes au niveau du serveur.
Pour une raison que je n'ai toujours pas cernée, il arrive que des déconnexion ne se fassent pas. on a donc des tâches fantome qui tournent et il faut rebooter le serveur quand il est plein de ces cochonneries.

D'autre part, même si cela demande un peu plus de temps, le fait de refaire les requêtes dans SQLServer sera un confort on ne peut plus intéressant pour les utilisateurs. En effet, il est possible de créer des PS qui ont l'avantage d'être compilées. et donc, leur exécution est beaucoup plus rapide. Enfin, on a du vrai C/S, ce qui ne sera pas vraiemnt les cas avec des tables attachées dans Access.

Alors, oui, c'est une migration "en douceur" que tu proposes =JBO= , mais (et ceci est mon avis personnel) ce n'est pas ce qui est le plus intéressant pour les utilisateurs finaux.

En fait, poissonsoluble, tu peux poser la question comme cela :
Qu'est-il préférable de faire ? Quelque chose de nickel, qui tourne bien, sans souci de débit ni de maintenance, mais qui va prendre un peu de temps, ou quelque chose de vite fait et qui ne sera pas forcément facile à maintenir, ni parfaitement conforme aux attentes ?

[cbleas]

bonjour,

si tu bascules sur sql server tu pourras te passer d'access car ton application eb VB6 par ADO.

bonne journée

[poissonsoluble]

Ici il s'agit d'une application VB6/???/MDB/JET.
.....
_

Il s'agit de VB6 avec ADO, si c'est bien ça que tu voulais savoir.

[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