Interopérabilité MS Access – Importation de données

Je travaille sur un exe pour exporter SQL vers Access, nous ne souhaitons pas utiliser DTS car nous avons plusieurs clients qui exportent chacun des vues différentes et la charge de travail nécessaire à la configuration et à la maintenance des packages DTS est trop importante.

* Edit: ce processus est automatisé chaque nuit pour de nombreux clients. Il est donc nécessaire de lancer et de contrôler l’ensemble du processus au moyen d’un curseur dans une procédure stockée. En effet, les données doivent être filtrées par projet pour l’exportation.

J’ai essayé de nombreuses manières de transférer des données SQL dans Access et le plus prometteur a été d’utiliser Access interop et d’exécuter une

doCmd.TransferDatabase(Access.AcDataTransferType.acImport...

J’ai rencontré un problème d’importation depuis des vues. Si vous exécutez l’importation manuellement, il semble que la vue ne commence pas à renvoyer les données assez rapidement. Par conséquent, une boîte de dialog MessageBox s’affiche pour indiquer qu’elle a expiré. Je pense que cela se produit également en interopérabilité, mais comme elle est cachée, la méthode ne revient jamais!

Est-il possible pour moi d’empêcher ce message de s’afficher ou d’augmenter le délai d’attente de la commande d’importation?

Mon plan d’attaque actuel consiste à aplatir la vue dans une table, puis à importer à partir de cette table, puis à supprimer la table aplatie.

Heureux pour toutes suggestions sur la façon de résoudre ce problème.

Modifier:

Plus d’infos sur ce que je fais:

Nous avons plusieurs clients qui ont chacun un modèle de données standard. L’un des ‘modules’ est un exportateur d’access (sproc). Il lit les vues à exporter depuis une table de parameters, puis exporte. Les vues sont filtrées par projet et un fichier d’access est créé pour chaque projet (chaque vue possède un champ de projet).

Nous utilisons SQL 2005 et ne passons pas rapidement à SQL 2005, nous allons probablement passer à 2008 dans quelques mois.

Nous avons ensuite un travail d’exécution de module qui exécute le module configuré sur chaque firebase database. De nombreux travaux d’importation / exportation / autres s’exécutent dans l’exécution de ce module, et l’exportateur d’access doit pouvoir s’intégrer à ce cadre. J’ai donc besoin d’un exportateur générique SQL -> Access pouvant être configuré via notre framework de parameters.

Actuellement, le sproc appelle un exe que j’ai écrit et mon exe ouvre l’access via interop, je sais que c’est mauvais pour un serveur MAIS l’exécution du module est écrite de sorte qu’un seul module s’exécute à la fois, de sorte que la procédure ne s’exécutera plus qu’une instance à la fois.

Avez-vous essayé d’utiliser VBA? Vous avez plus d’options pour configurer les connexions et je suis sûr que j’ai déjà utilisé un ajustement de délai d’attente dans ce contexte.

En outre, j’ai généralement trouvé qu’il était plus simple de consulter directement une vue (tant que vous pouvez vous connecter à un nolock ou tolérer le temps nécessaire au transfert); Cela peut être une bonne raison de créer la table temporaire intermédiaire.

Il pourrait également être avantageux d’ouvrir explicitement Acces en mode mono-utilisateur pour ce genre de choses.

Nous avons utilisé ADO pour nous connecter aux données source et cible. Vous pouvez définir les valeurs de délai de connexion et de commande selon vos besoins et lire / append à chaque jeu d’enregistrements.

Pas particulièrement rapide, mais nous avons pu le laisser fonctionner pendant la nuit.

J’ai choisi un moyen de le faire.

http://support.microsoft.com/kb/317114 décrit les étapes de base pour démarrer le processus d’access.

J’ai transformé le processus en une variable de classe au lieu d’une variable locale de la méthode ShellGetApp. De cette façon, lorsque j’appelle la fonction Quit pour l’access, si elle ne se ferme pas pour une raison quelconque, je peux arrêter le processus explicitement.

 app.Quit(Access.AcQuitOption.acQuitSaveAll); if (!accessProcess.HasExited) { Console.WriteLine("Access did not exit after being asked nicely, killing process manually"); accessProcess.Kill(); }

J’ai ensuite utilisé une fonction de délai d’attente de méthode ici pour donner un délai d’attente à l’appel d’access. Si le délai expire, je peux également arrêter le processus d’access (le délai peut être dû à une fenêtre de dialog qui s’ouvre et je ne veux pas que le processus soit bloqué pour toujours. J’ai la méthode du délai d’attente ici.

Implémentation du délai d’attente générique C #

Je suis content que vous ayez une solution qui fonctionne pour vous. Pour le bénéfice des autres lecteurs, je mentionnerai que SSIS aurait été une solution possible à ce problème. Notez que la différence entre SSIS et DTS est à peu près la nuit et le jour.

Il n’est pas difficile de paramétrer le processus d’exportation, de sorte que pour chaque client, vous pouvez exporter un ensemble de vues différent. Vous pouvez parcourir les lignes d’un fichier texte contenant les noms de vues ou utiliser une requête sur une firebase database de configuration pour obtenir la liste des vues. Les autres parameters peuvent provenir de la même firebase database de configuration, client par utilisateur et / ou utilisateur.

Si nécessaire, il serait également possible d’effectuer un pré-traitement et un post-traitement par client, en exécutant un processus enfant ou un pacakge, si celui-ci est configuré.