Discussion :

[FILK78]

Bonjour,

Je tente de vous exposer mon problème clairement et sobrement :

L'an dernier, nous avons mis en place un ERP 'MS Dynamics NAV' sur une base SQL. J'ai créé une base Access de Reporting de cet ERP. Cette base access est composée :
- de tables de reporting (tables access)
- de tables attachées (tables sources de l'ERP).

Dans ma base access, J'ai du code vba qui va mettre à jour cette base de reporting (je rapatrie les données, je les dispatche entre mes tables access et j'effectue quelques traitements / transformations). Temps de mise à jour : 00:03:30 => acceptable.

Et là, je me dis que ce serait bien que ma base de reporting soit une vraie base SQL. Je demande donc à l'IT de créer une base SQL sur le serveur de test. Je crée exactement les mêmes tables que les tables de reporting créées dans Access.

Je duplique ma base access et je remplace les tables access par des tables attachées à ma base SQL de reporting. Au point de vue fonctionnel, ça marche. Par contre, au niveau performance, je dois être à 4 heures de mis à jour par rapport aux 3 minutes 30 !!!


Donc, ce que je constate :

- l'INSERT INTO entre tables attachées de deux serveurs différents est une catastrophe pour les performances
- en remplacant l'INSERT INTO par un 'select' et un addnew en VBA, c'est un peu mieux (étrange comme résultat)
- je vais bien plus vite en faisant [server Prod] => Access Local => [Server Test] que [server Prod] => [Server Test] (encore plus étrange comme résultat)


Mes questions :

En fait, je demande à des gens d'expérience de réagir sur le projet. La réponse n'est peut-être pas technique: peut-être que mon projet est tout simplement mal pensé.

Dans le cas où je pilote depuis access (ce qui m'arrange évidemment), devrais-je m'y prendre autrement ?


Merci par avance en tous cas. Je suis preneur de tout conseil.

Fil

[montreal_1]

Bonjour,

Je travaille sur une base de données SQL Server à partir d'une applications access et j'ai de très bon temps de réponse !
Presque équivalent au temps de réponse que j'avais en travaillant sur des tables access.

A l'une ou l'autre reprise, j'ai eu de mauvais temps de réponse avec des clauses WHERE trop complexes.
La solution a toujours été de simplifier le code SQL, quitte effectivement à réaliser dans mon application access une requete SELECT intermédiaire que je scanne ensuite pour réaliser de nouvelles requêtes.
Mais les mauvais temps de réponse s'évaluaient en minute ...

Par contre, dans un projet access, je n'ai jamais travaillé sur plusieurs base de données SQL Server conjointement !

Raoul

[FILK78]

Merci pour la réponse.

Ici, pas de SQL complexe, un simple insert into avec un select en source. Par contre, 200 000 lignes avec une trentaine de colonnes.

Je n'ai pas fini mes tests mais il me semble :

SQL SERVER => Access Local : perte de performance
Access Local=> SQL SERVER : temps acceptable

(Attention, je ne pense pas avoir fait suffisamment de tests pour en être certain)

Du coup, je me demande si on peut quand même optimiser en changeant le driver ?

FIL

[Jean-Philippe André]

Salut,

les autres éléments à prendre en compte sont potentiellement les transactions, le fait d'avoir un système de réplication/mirroring sur tes serveurs.

De plus, le fait d'être en local vs en réseau a un impact non négligeable sur l'accès aux données. EN passant d'access (format fichier) à SQL serveur (format client/serveur) tu changes aussi de catégorie de BDD

[montreal_1]

Cet insert rempli par un select ... comment access gère-t'il celà ?

Les données du select (serveur prod ) transitent quand même dans access avant d'être réexpédiée vers serveur test !!!

Dans quelle structure ces données sont-elles sauvegardées ? Dans la mémoire vive ? Quel temps cela prendrait-il avec 1000 ou 10000 données ? Je serais curieux de savoir !


Une solution certaine est d'exécuter cet insert directement dans serveur test. Insert est mis dans une procédure stockée ... et la procédure stockée est lancée depuis access.

C'est simple à faire ! Mais je ne peux donner plus d'explication n'ayant pas implémenté ce code dans mon application.

[montreal_1]

Je poursuis ...

toute réflexion faite, je pense que votre insert ... est envoyé et exécuté dans serveur_test ...

serveur_test patauge pour trouver les données de serveur_prod ...

Raoul

[FILK78]

oullllaaaa ! Simple à faire... Je ne suis pas développeur pro et je galère comme un petit fou.


Pour en venir à la procédure stockée, c'est une voie que j'explore également et j'y vais pas à pas :

- j'ai appris hier à faire une procédure stockée simple (le delete avant de faire l'insert)
- j'ai vu sur google comment appeler en vba la procédure stockée

=> donc le niveau 1 de la procédure stockée, j'ai bien pigé: c'est testé et ça marche. Ceci étant, le delete, c'est pas ce qui me fait le plus gagner de temps ...il faut que je passe sur une procédure stockée faisant un insert into entre deux tables de serveurs différents.


Avant d'avoir cette prétention, il me faut déjà être capable de faire un select sur un serveur externe depuis ma base et c'est là où je bloque.


1/ J'ai testé Select * From [Monserveur].[MaBase].[dbo].[MaTable]

=> retour d'erreur pour me signaler que le serveur doit être dans sysservers (c'est une vue système sur ce que j'en ai vue). Je dois donc passer par sp_addlinkedserver


2/ Je tente mon sp_addlinkedserver

Je crée une procédure stockée du type EXEC sp_addlinkedserver @server='SRVIVASQL01'

J'ai essayé plusieurs manières d'ajouter un serveur correctement et ca plante systématiquement. Mis à part pourrir la vue système sysserver du serveur de test, je ne suis pas arrivé à grand chose. Du coup, je bloque sur le select.

Non seulement je ne suis pas sûr du rajout du serveur mais en plus je ne suis pas certain d'avoir suffisamment de droits.


Pour cette raison, j'avance en parallèle sur Access, domaine où je me sens à l'aise même si j'ai l'impression que ce n'est pas la bonne manière.


Merci encore pour les participations.

FIL