Discussion :

[steelidol]

Bonjour !

J'ai vraiment besoin d'aide. En ce moment je dois convertir des centaines de vues qui ont été faite sur Access en T-sql pour quel fonctionne sur SQL server. Mais je n'ai que des problème!! Cela fait maintenant près de 2 semaines et je m'arrache les cheveux! Je n'aime vraiment pas Access. En fait j'ai parfois des vues qui contiennent des erreurs de parenthèse ou de crochet et Access ça ne le dérange même pas alors que ce sont des erreurs plutôt importantes et qu'il faut corriger pour le T-SQL!!
Bon tout ça pour dire que un de mes plus gros problème ce sont toutes les fonctions Access qui peuvent être utilisé dans les vues comme des DLookup, Dsum, IIF etc....

Corrigé tout ça c'est pas mal de travaille et ça avance pas vite alors je me dis que plutôt que de tout convertir ces fonctions je pourrais peut-être simplement les recréer en t-sql mais je n'y arrive pas. Prenons l'exemple du Dlookup.
Si j'ai DLookup("MonChamp","MaTable","Condition = 1") alors en T-SQl se serait SELECT MonChamp FROM MaTable Where Condition = 1

Je me suis fais une fonction de type Scalar mais il semble que je ne puisse pas y avoir accès dans mes vues. Alors j'ai tenté de créer une fonction de type Table. Je peux alors y avoir accès dans ma vue mais il semble que dans ce genre de fonction on ne peut faire appel à la fonction EXECUTE que j'ai besoin car il faut que mon SELECT soit dynamique. Il faut que dans ma fonction je puisse faire un EXECUTE('SELECT ' + @Matable + ' FROM ' + @MaTable + ' WHERE ' + @Condition). Malheureusement il semble que je ne puisse pas faire de execute dans une fonction TABLE. Parcontre dans une fonction Scalar cela fonctionne mais je ne peux pas y accéder dans mes vues.

Quelqu'un sait si ce que je veux faire est possible avant que je me sois arracher tous les cheveux sur la tête

Merci !

[SQLpro]

Malheureusement et heureusement il n'y a aucune solution !

Access est un salmigondi se SQL et de code VB qui n'est absolument pas portable en MS SQL Server.

Il n'est pas portable et ne doit surtout pas être porté tel quel !
En effet en traduisant telle quelle votre appli Access en appli SQL Server vous aller diminuer les perf car Access vise à faire de l'accès fichier tandis que MS SQL Server fait du service de données (RAM).
les deux modèles sont strictement incompatible en matière de portage et le report de l'un sur l'autre va conduire à la catastrophe en terme de perf.
Il y a moins d'un an j'ai audité une telle application produite par un grand éditeur qui avait racheté une petite compagnie et j'ai rendu un arrêt de mort pour cette même raison qui vous fait vous poser la question aujourd'hui...

En effet ce EXECUTE('SELECT ' + @Matable + ' FROM ' + @MaTable + ' WHERE ' + @Condition) va devoir être envoyer des millers de fois, en fait un pour chaque colonne de chaque ligne de chaque table... Meilleur moyen de tuer votre serveur...

Le seul remède est de vous pencher sur une refonte vers un modèle approprié et de surtout laisser tomber vos mauvaises habitudes acquises avec Access !

Voyez l'extrait de l'article que je suis en train d'écrire pour un magazine sur SQL Server...

A +

[steelidol]

Merci beaucoup pour votre réponse ! Je craignais ce genre de réponse mais là au moins je suis certains de ce que je dois faire. Je vais donc continuer à refaire manuellement les vues. J'ai toujours travaillé sur SQL-Sever et Oracle mais là où je travaille il faut reprendre tout un projet qui à été fait en Access alors puisque je ne connais pas la raison de toutes ses vues je me disais qu'en les traduisant tel quel les chances d'erreurs seraient moins élevés. Je n'avais pas pensé aux performances....j

Je vais me remettre au travaille alors

Merci beacoup !

[Fabien Celaia]

Sans vouloir revenir sur les dires de Frédéric, la date de l'arrêt de mort dépendra de la façon utilisée pour développer en Access.

Une kyrielle de petites applications propres peuvent être portée simplement en remplaçant les tables Access par des tables attachées sur un SGBDR digne de ce nom.

Ensuite reste le problème lié aux performances, et là, certaines requêtes Access pourraient devenir nettement meilleures en étant réécrites en SP ou - pourquoi pas - en vues, ce qui empêchera Access de remonter la totalité des lignes impactées des tables attachées pour jouer ses requête sur la partie cliente (car là, c'est la "ligne verte").

En résumé, plus lôn se sera éloigné du SQL pur et dure pour rentrer dans des spécificités Access, et plus le portage sera pénible et lourd.

[m-mas]

juste pour ne pas avoir un abus de langage :
Pas de vues dans Access mais des requêtes
Pas de langage T-SQL dans Access mais du sql ou du VB !

Morsi.