Méthode 'SaveAs' de l'objet _Document (Word) = "Serveur RPC indisponible" parfois ?

Bonjour,


Pour résumer rapidement j'ai implémenté une méthode qui se charge de faire un publipostage sous Word, d'enregistrer le fichier et de rendre la main à l'utilisateur...

Seulement voilà avec certains documents WORD sous Windows 2000, avec un compte utilisateur à droit restreint (pas admin) et sous Word 2000 je me tape une erreur "Serveur RPC Indisponible" lorsque j'appelle la méthode 'Document.SaveAs(...'
L'appel échoue immédiatement (pas de timeout comme je le pensais deprime abord), pour une raison que j'ignore l'objet '_Document' semble être devenu indisponible.

Seulement cela ne se produit pas tout le temps, j'aurai même tendance à dire que lorsque pas mal de conditions sont réunis (celles que je vous ai indiqué plus haut).

Si quelqu'un a une idée de ce qui peut me causer cette erreur car j'ai tenté plusieurs implémentations, j'ai fait pas mal de recherche, en vain...

éventuellement je posterai les détails de l'implémentation si personne ne peut m'aider dans un premier temps.

Merci d'avance.

Citation:

---

Serveur RPC Indisponible

---

Cela signifie que la liaison COM a été rompue entre le programme et le serveur COM (Word).
Je te conseille de te pencher sur les pistes suivantes : antivirus, protection contre les vers, firewall, etc.
Peut-être trouveras-tu des éléments de réponses en consultant le journal de l'observateur d'événements...
Bon courage.

Citation:

---

Envoyé par cmen76

Cela signifie que la liaison COM a été rompue entre le programme et le serveur COM (Word).
Je te conseille de te pencher sur les pistes suivantes : antivirus, protection contre les vers, firewall, etc.
Peut-être trouveras-tu des éléments de réponses en consultant le journal de l'observateur d'événements...
Bon courage.

---

Merci beaucoup pour ta réponse, d'après toi lors de l'appel à la méthode 'SaveAs' (et donc lors de la sauvegarde du fichier) quelquechose vient entraver la tache et casse la liaison entre objet et serveur COM ?

Ce que je ne comprend pas c'est pourquoi cela arrive-t-il uniquement avec certains document qui en apparence n'ont rien de particulier par rapport aux autres (si ce n'est d'après l'utilisateur une plus grande complexité dans les scripts peut-être), enfin en y réfléchissant un peu cela aurait tendance à aller dans le sens c'un antivirus qui pourrait foutre la merde. Je vais peut-être essayer d'inspecter un peu de ce côté...

Sinon juste pour infos quelle est la différence l'objet '_Application' et 'TWordApplication' ? Je sais que j'ai rencontré des problèmes de "synchronisation" avec en manipulant le "TWordApplication" : messages d'erreurs de type 'un appel asynchrone a été effectué...".
car j'ai l'impression que "TWordApplication" effectue des appels asynchrones (ce qui peut poser pas mal de problèmes) contrairement à '_Application' .

J'avoue que je ne comprend pas toujours le mécanisme qui déclenche l'erreur "Serveur RPC indisponible"...

TWordApplication est un objet qui encapsule les appels au serveur COM _Application. En fait, il est censé permettre une manipulation de l'objet COM plus intuitive (façon Delphi) qu'en s'y attaquant directement (que des OLEVariant...). En plus, il ajoute des "event sinks" c'est-à-dire qu'il est notifié de quelques actions effectuées par l'utilisateur sur l'objet OLE (nouveau docuement, quitter, etc).
En ce qui concerne COM, c'est un peu une boîte noire...
Un serveur COM est invoqué (par la création d'une co-classe) ; s'il est déjà chargé, il incrémente son compteur d'instance. Quand ce dernier revient à 0, il se libère de la mémoire.
Pour avoir travaillé sur des objets DCOM (Distributed COM, soit un client COM et un serveur COM sur 2 postes différents d'un réseau), si une panne réseau intervient pendant une transaction, on obtient le même message 'Serveur RPC indisponible'...
Fais quelques recherches sur OLE, COM, DCOM pour plus de précision. MSDN par exemple.

Citation:

---

Envoyé par cmen76

TWordApplication est un objet qui encapsule les appels au serveur COM _Application. En fait, il est censé permettre une manipulation de l'objet COM plus intuitive (façon Delphi) qu'en s'y attaquant directement (que des OLEVariant...). En plus, il ajoute des "event sinks" c'est-à-dire qu'il est notifié de quelques actions effectuées par l'utilisateur sur l'objet OLE (nouveau docuement, quitter, etc).
En ce qui concerne COM, c'est un peu une boîte noire...
Un serveur COM est invoqué (par la création d'une co-classe) ; s'il est déjà chargé, il incrémente son compteur d'instance. Quand ce dernier revient à 0, il se libère de la mémoire.
Pour avoir travaillé sur des objets DCOM (Distributed COM, soit un client COM et un serveur COM sur 2 postes différents d'un réseau), si une panne réseau intervient pendant une transaction, on obtient le même message 'Serveur RPC indisponible'...
Fais quelques recherches sur OLE, COM, DCOM pour plus de précision. MSDN par exemple.

---

Merci, je le voyais ainsi mais pourquoi TWordApplication ferai des appels asynchrones ?? Peut-être justement pour sa gestion d'événements...

En fait j'ai déjà pas mal regardé mais quelques "trucs" me semlbent un peu flous. moi j'utilise COM uniquement en local (sur le même poste), uniquement pour une communication inter-application. Je passe souvent par des controles activeX car c'est simple d'usage par parfois j'ai des erreurs "serveur RPC indisponibles" pour des raisons que j'ai un peu de mal à cerner. Mais souvent cela arrive conjointement à l'utilisation de composant asynchrone...

Je ne sais pas à quel niveau pourrait se déclencher une transaction asynchrone. Par contre une chose est certaine c'est que RPC signifie Remote Procedure Call. Donc même si l'appel reste local, il est identifié comme pouvant être distant (probablement un CreateRemote sur la coclasse).
Et si le serveur est de type COM+, il y a fort à parier que MSDTC (Microsoft Distributed Transaction Coordinator) soit invoqué, et là, on nage en plein asynchrone...
Il faudrait contacter un gourou de l'administration Windows pour savoir quels sont les droits à paramétrer et sur quels objets, mais là franchement ça dépasse largement mes connaissances.:roll:

Regarde ici au cas où,
http://support.microsoft.com/search/...de=r&cat=False
Sinon sur le forum il y a qq posts sur le sujet.

Merci bien.

Effectivement, je ne sais pas comment est implémenté le "TWordApplication" en interne et j'avoue que je suis très loin de maitriser tous les aspects et mécanismes de COM/COM+/DCOM...

Tout ce que je sais (et pour revenir à mon problème) c'est que mon client dispose bien d'un anti-virus mais qu'il n'a aucune moyen de le désactiver. Et comme le service informatique du client est en congé la seule solution a été pour moi de tenter de reproduire le contexte d'utilisation.

J'ai donc installé la même version de mon appli, sur le même OS (Win2000), avec la même version de Word (Word2000), avec le même document WORD et le meme anti-virus (même version). La seule différence concerne les droits utilisateurs... je ne les connais pas en détail donc je me suis contenté de faire un utilisé "non administrateur" sur mon serveur de domaine et...
pas moyen de reproduire le problème ! du coup je me demande s'il s'agit vraiment de l'antivirus. C'est peut-être autre chose, mais cela a très probablement à voir avec la config du PC puisque sur d'autres postes plus réçents du clients (équipés au moins du même Word mais sous Windows XP et avec un profil utilisateur différent bien qu'équivalent en droit) l'impression fonctionne bien. Hum... pas facile de cerner d'où vient le problème...

Je vais jeter un oeil au lien voir si je peux trouver la réponse à mon problème...


[Edit] : Je précise que dans mon cas je fais en sorte que Word ne soit visible à l'utilisateur uniquement lorsque je ne travaille plus avec l'objet automation (déjà libéré), ce qui empêche que l'utilisateur "casse" manuellement la liaison COM.

As-tu vérifié ce point ?
http://www.developpez.net/forums/sho...C+indisponible

Citation:

---

Envoyé par Laurent Dardenne

As-tu vérifié ce point ?
http://www.developpez.net/forums/sho...C+indisponible

---

Oui j'ai vérifié ce point, ou plutot mon problème est différent (j'utilise pas TWordApplication mais '_Application' que j'affecte à 'nil' à la fin de la méthode). Moi j'ai toujours cette erreur RPC dès le premier appel mais avec un certain document WORD uniquement (et sous Win2000/Word2000 sur un certain poste..), tandis que si j'appelle la même méthode qui fait le même traitement sur un autre fichier je n'ai pas le problème.

Je pense qu'il s'agit de quelquechose de plus vicieux malheureusement. Je n'ai malheureusement rien trouvé qui puisse m'aider dans le lien précédent...

Je dois dire que je ne vois vraiment pas de solution à part demander au client de mettre à jour son poste (enfin le réinstaller avec une autre version de WORD peut-être) mais voilà c'est bof bof (même si je pense qu'il doit yavoir quand même quelquechose qui cloche sur le poste), et je suis pas sur que ce soit possible pour lui. Enfin bref c la galère :-/ ...

Yep !

Peut-être à côté de la plaque, mais sait-on jamais ?

Citation:

---

(...) avec un certain document WORD uniquement (...)

---

Un problème de macro ?
Ou de droits à propos des macros ? (Word, Outils / Macros / Sécurité...)

Mes 2 cts,
JP

Le document qui pose pb fonctionne-t-il sur un autre poste avec ton appli ?

L'enregistrer, sous word, sur un autre post pose pb ? et sinon un nouvel essai, aprés cette opération, provoque-t-il la même erreur ?

Un simple prg de test, avec SaveAs provoque le même pb ?
La méthode Save fonctionne ?
Les versions d'Office +SP+patch sont identiques ?

Tu n'as pas répondu à Cmen76 au sujet du msg d'erreur dans l'eventlog.

A mon avis réinstaller le poste est une bonne approche, maintenant faut voir si le le client veux connaître l'origine du pb ou une juste une solution.

Jipété> hum, je ne pense pas car j'ai tenté de reproduire le même contexte (utilisateur à droit restreint/win2000/word2000/antivirus identique) et je n'ai pas l'erreur. Mais il est vrai qu'au niveau des droits utilisateurs je n'ai pu refaire à l'identique.


Laurent Dardenne> oui. En fait la lettre pose problème sur un certain nombre de poste identique (UC et OS). Mais sur d'autres elle passe sans problème (UC et OS différent).

Il faudrait effectivement que je réalise le test dont tu me parle mais je n'en ai pas la possiblité actuellement. De même dans les journal des événements le client n'a pas accès à tout le journal complet (sécurité par exemple est indispo) et pour le reste il n'y avait rien d'intéressant/concernant le problème.

Citation:

---

Envoyé par ZZZzzz2

Laurent Dardenne> oui. En fait la lettre pose problème sur un certain nombre de poste identique (UC et OS). Mais sur d'autres elle passe sans problème (UC et OS différent).

---

ha, ici la réinstallation n'est donc plus d'actualité :?

Essaie ceci :
sélectionner l'intégralité du doc et copie le
ouvre un nouveau doc
colle les infos copiés précédement
sauve dans un nouveau doc
réessai les même manips avec ce nouveau fichier.

La structure du fichier est-elle complexe (des liens, des objets imbriqués) ?

'Jour !

Citation:

---

En fait la lettre pose problème sur un certain nombre de poste identique (UC et OS). Mais sur d'autres elle passe sans problème (UC et OS différent).

---

« la lettre » ? Le document du post d'origine, je suppose ?
En admettant que oui, moi, vraiment je creuserais là :
(UC et OS) vs (UC et OS différent)
J'ai entendu/lu plein d'horreurs à ce propos.

Les idées de Laurent sont sympa.

Mes 2 cts,
--
JP

Citation:

---

Envoyé par Jipété

'Jour !



« la lettre » ? Le document du post d'origine, je suppose ?
En admettant que oui, moi, vraiment je creuserais là :
(UC et OS) vs (UC et OS différent)
J'ai entendu/lu plein d'horreurs à ce propos.

Les idées de Laurent sont sympa.

Mes 2 cts,
--
JP

---

En fait pour l'OS il s'agit d'un master, car le parc informatique est assez conséquent...le master contient donc des personalisations nécessaires au groupe, nous avons déjà rencontré un problème decompatibilité avec ce master et un appareil USB. Maintenant c'est avec des impressions de documents word (enfin la sauvegarde en réalité...)... Le problème étant que je ne parviens pas à reproduire le problème et donc évidement je ne peut pas faire grand chose. Je n'ai malheuresement pas la possiblité de réaliser des tests sur les postes incriminés.
Et comme tu t'en doutes je ne peux pas leur demander de modifier leur master comme ça...


Laurent Dardenne> Merci, Je vais demander à un utilisateur de réaliser la manipulation dès qu'il pourra et je te tiendrai au courant. Le document n'est pas vraiment complexes (ça reste une document Word) mais il y a quelques formules et champs de fusion...

Citation:

---

Je n'ai malheuresement pas la possiblité de réaliser des tests sur les postes incriminés.

---

"J'ai la voiture en panne mais non, monsieur le garagiste, je ne peux pas vous la laisser. Dépannez donc par télépathie !":roll:

Bon courage !;)
--
jp

Citation:

---

Envoyé par Jipété

"J'ai la voiture en panne mais non, monsieur le garagiste, je ne peux pas vous la laisser. Dépannez donc par télépathie !":roll:

Bon courage !;)
--
jp

---

Hahaha, enfin ce que je voulais dire c'est que je n'ai pas la possibilité de tester directement car le poste n'est accessible qu'aux utilisateurs. Et ils ne peuvent pas s'en passer, je peux y accéder mais de manière très contraignante donc évidement ça avance lentement :( ...

up

:arrow: As-tu mené une comparaison exhaustive des options de Word sur les 2 environnements différents ?
Je pense notamment à la mise à jour des liaisons, des champs, et tous ces trucs...
:arrow: La fusion est-elle faite avec une source de données document Word, ou d'un autre format ? D'autres fusions identiques passent-elles ?