Discussion :

[argyronet]

Bonjour,

2/ Disons que si tu veux un max de performances et un projet SQL digne de ce nom, il est recommandé de transformer tes requêtes comme telles. On ne peut pas mélanger les deux. Au sein de ce thread, tu as un bon résumé du pourquoi faire ceci plutôt que cela, exposé exhaustivement par JBO.

1/ Effectivement, la majorité des requêtes enregistrées sont dédiées à être exploitées par des Forms ou des Reports mais elles peuvent être aussi exécutées sur le pouce en VBA via des chaînes SQL avec un composant DAO.

Par le suite, tu exploites les vues comme tu exploites des tables non triées où l'intérêt se resume à obtenir des requêtes multi-tables et tu exploites les procédures stockées avec des paramètres que tu passes dynamiquement par code avec un objet ADO.

Le tutoriel que j'ai écrit ne possède pas tous les aléas des difficultés auxquelles tu seras confronté car il reste assez générique : il est là pour guider dans ta démarche et aussi et c'est un point important, estimer la charge de travail qui se présentera à toi.

Dans ton cas perso, Access te facilitera la tâche pour la composition de ton application beaucoup plus aisément (je n'ai pas dit facilement mais presque) qu'avec Visual Basic.

Argy

[meandreux]

Tu as écrit :

"Par le suite, tu exploites les vues comme tu exploites des tables non triées où l'intérêt se resume à obtenir des requêtes multi-tables et tu exploites les procédures stockées avec des paramètres que tu passes dynamiquement par code avec un objet ADO"


Les vues devront-elles être appelées forcément par ADO ? N'y a t'il pas un moyen de les récupérer de façon plus aisée dans ACCESS (comme un objet <Table> sous l'onglet "Tables" par exemple) ?

Ce qui veut dire que je devrai éplucher tous les reports et forms et voir où sont appelées les requêtes pour les transformer en vues ou proc stock ?


Par ailleurs, peux tu approfondir la notion de ADP/ADE ?

Merci encore

[argyronet]

1/ Bien entendu... VBA n'est pas oligatoire, heureusement d'ailleurs.
Regarde la 1ère image du tuto rubrique "3. Quand et pourquoi migrer ?"
Tu peux voir les vues et les PS.

2/ En gros, ADP est à MDB ce que ADE est à MDE...

Argy

[meandreux]

OK merci encore.

Je pense qu'on me reverra très bientôt sur cette discussion

[meandreux]

Bonjour,

Mon audit de migration de SQL vers SQL Server a démarré.

L’application existante est dans un état sinistre (et je pèse mes mots).

Le modèle relationnel est hallucinant et digne de faire partie du bêtisier ACCESS.

- Certaines tables ont des clefs de type « Texte » allant jusqu’au nombre de 10 pour une même table !
- Certaines tables possèdent des clefs primaires de type « Mémo », lors de l’appel de l’assistant Migration SQL cela génère un beau message d’erreur car SQL ne génère pas de clefs sur des champs de type « nText ».
- Existence d’alias dans le MCD (par exemple, une table du nom <Table> se fait appeler <Table_1> et <Table> pointe sur <Table_1> par son jeu de clefs primaires : comment se comporte l’assistant migration SQL devant un tel scénario ?)
- Normalisation farfelue : existence d’accents, d’espaces, de caractères spéciaux (exemple : &) sur les objets (tables, etc…) de l’application
- Sur une même table, existence de jointures par plusieurs dizaines avec une foison de mises à jour et de « delete » en cascade, sans parler des contraintes d’intégrité appliquées.


L’assistant migration SQL Server a atteint ses limites et ne peut générer le fichier ADP.

La base de données n’est même pas scindée car il s’agit d’un fichier MDB (contenant formulaires, états, requêtes) qui pointe sur un fichier MDB (contenant d’autres requêtes, et les tables).

Question 1 :
Peut-on selon vous l’assimiler à un environnement MDE – MDB ?

Question 2 :
Peut-on créer des procédures stockées, des vues, des fonctions SQL en restant dans un environnement MDE-MDB ?

Question 3 :
Avez-vous une idée pour rapatrier les données des tables ACCESS dans SQL sans passer par l'assistant migration SQL ?

Question 4 :
Peut-on générer un fichier ADP sans passer par l’assistant migration SQL ?

Merci d’avance pour vos réponses et vive le code propre

NB : l’application tourne sous ACCESS 2002.

[argyronet]

Eh bien tu refais tout...
Il vaut mieux reconstruire que de bâtir sur des parpaings mous...

Question 1 :
Peut-on selon vous l’assimiler à un environnement MDE – MDB ?
Tu peux toujours scinder ta base... Ca ne cahngera pas le problème que tu rencontres au niveau de la migration. Donc tu n'as pas à te soucier de ce coté là.

Question 2 :
Peut-on créer des procédures stockées, des vues, des fonctions SQL en restant dans un environnement MDE-MDB ?
Oui, dès que le projet est créé, tu peux ajouter des Vues et des PS depuis Access.
Question 3 :
Avez-vous une idée pour rapatrier les données des tables ACCESS dans SQL sans passer par l'assistant migration SQL ?
Par un code musclé utilisant des fonctions de conversion idoines et un objet ADO, tu pourra migrer l'ensemble de tes données (INSERT)
Question 4 :
Peut-on générer un fichier ADP sans passer par l’assistant migration SQL ?
Oui, Fichier, Nouveau, Projet mais je te conseille d'avoir ta base SQL déjà en place avec toutes les tables propres incluses...

Argy

[meandreux]

Ok mais supposons que je veuille rester en environnement MDE - MDB et que je veuille lier mes tables ACCESS à une base SQL par lien ODBC (méthode préconisée par JBO au début de cette discussion parce que le coût de la mise en place est moindre ou parce qu'on désire répondre à une situation d'urgence),



en plus de l'alimentation de ces tables SQL, faut-il :

- que je crée les clefs primaires de ces tables SQL ?
- que je crée les clefs étrangères ?
- les triggers (pour les mises à jour et delete en cascade) ?


Merci

[argyronet]

Oui, mais coté perfs, autant rester en MDB-MDE car là, tu vas constater une dégringolade digne de ce nom...

Ta situation d'urgence ne réparera pas le mauvais développement de la structure actuelle que tu as exposé. Dans un cas comme dans l'autre, tu seras contraint de construire tes tables dans SQL Server.

Argy