Export d'Access vers Excel en utilisant Access Runtime 2007

Bonjour,

j'ai fait une application sous Access 2007 qui exporte des données vers Excel. Avec la version complète, aucune erreur, tout se passe très bien. Avec la version Runtime, il génère une erreur qui conduit à fermer l'application.

Le pire c'est que en supprimant le bouton ou en le renommant, ça remarche pendant un temps avec les deux versions. Et puis, il génère de nouveau une erreur sous la version Runtime...

Comment eviter cela ? Comment rendre l'export de données vers Excel moins 'délicat' ?

Merci de votre réponse, parce que, là, moi, je sêche...

Bonjour

Peut-être un problème dans ton code, ouvres-tu une session Excel, et la fermes-tu correctement ?

Philippe

Merci pour une réponse si rapide !

Voici le début et la fin de mon code (il est très très long, jusqu'à 1260 lignes) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

Public xlApp as Excel.Application Public xlSheet as Excel.Worksheet Public xlBook as Excel.Workbook   sub Export_Excel 'Initialisations Set xlApp = CreateObject("Excel.Application") Set xlBook = xlApp.Workbooks.Add   'Ajouter une feuille de calcul Set xlSheet = xlBook.Worksheets.Add xlSheet.Name = "Marché de travaux"   ' écriture dans la cellule de ligne 1 et de colonne 1 xlSheet.Cells(1, 1) = "MP ACCESSOR" xlSheet.Cells(1, 1).Font.Bold = True     [...]     ' code de fermeture et libération des objets MSG = MsgBox(" --- Opération réussie ---" & vbNewLine & vbNewLine & _ "Le fichier Excel se trouve sur le bureau avec pour nom : " & xlBook.Name & "." _ & vbNewLine & vbNewLine & "Voulez-vous ouvrir ce fichier ?", vbYesNo, "Exportation des données") If MSG = vbYes Then xlApp.Visible = True Else xlApp.Quit End If   Set Enreg_T = Nothing Set xlSheet = Nothing Set xlBook = Nothing Set xlApp = Nothing   End sub

---

C'est un code que j'avais trouvé sur le net. Il fonctionne sans problème sur la version complète. Mais sur la version Runtime, ça marche puis si je retrafic quelque chose, ça ne marche plus. Alors je fais un peu de bidouille (je supprime le bouton et je remets le même, ou je mets mon code dans un module au lieu de le laisser dans le Userform...) et là ça remarche. Et parfois, au bout d'un certain temps, ça replante...

Là, franchement, je ne vois pas comment faire :(

Bonjour,

Il me semble que je fais pareil et ça marche bien...
Seule différence trouvée je fais xlbook.close avant xlapp.quit

Par contre attention ce type de code ouvre une cession excel à chaque exécution (et non une nouvelle fenêtre dans une cession existante le cas échéant). Il faut donc bien vérifier que la cession est systématiquement close. Le plus simple pour cela est d'aller voir dans le gestionnaire des taches s'il ne reste pas de processus excel.exe.

Y a-t-il une différence selon le choix de l'utilisateur ?
Quelle est l'instruction qui plante ?

NB : il est possible de tester l'existence d'une cession excel et de l'utiliser si oui mais dans ce cas si l'utilisateur a une saisie en cours sur un autre tableau ça bloque le code donc ce n'est pas préférable à mon avis...

Bonjour,

Que tu fais de l'OLE, si je puis encore employer ce terme, il faut spécifier dans une variable le nom du fichier qui se construit.
Tu fais ta moulinettes et tu quittes. Tu mets (tous) tes objets à Nothing.

Ne propose pas (jamais) de réafficher l'instance car là, tu fragilises le système dans le sens où elle est instanciée par son Parent et en l'occurence Access (Runtime ou non).

Ensuite, si l'utilisateur répond oui à ton message - euh, entre () je préfère mettre une case à cocher près du bouton qui stipule "Ouvrir après génération" comme cela, il fait ce qu'il veut. - alors tu lances Excel via un Shell comme ceci :

Code:

---

dblShell=Shell("EXCEL.EXE " & strXLFileName, 3)

---

où strXLFileName est le nom complet de ton fichier que tu as généré...

Tu ne devrais plus rencontrer de problème...

Argy

Un grand merci pour votre aide (super rapide, d'ailleurs !!!). Je vais essayer l'histoire de Argyronet et mettre aussi xlbook.close...

Je vous tiens au courant

Eh bah, malheureusement, problème non résolu.

J'ai fait les changements préconisés. ça marche très bien sur Access Complet (même si, en fait, ça a toujours très bien fonctionné sur la version complète), mais ça ne marche de nouveau pas sur Access Runtime. Donc, je vais rebidouiller un peu le code (mettre quelques lignes vides en plus ou changer deux trois mots par-ci, par-là) et je suis sûr que ça va refonctionner...

Mais est-ce que ça ne viendrait pas du fait que c'est une appli qui se trouve sur un réseau, qui fragiliserait le runtime ? Ne devrais-je pas diviser la base entre les formulaires et les données et mettre les formulaires sur le disque dur de chaque ordi et les données sur le réseau ?

Citation:

---

Envoyé par Humanisto

Ne devrais-je pas diviser la base entre les formulaires et les données et mettre les formulaires sur le disque dur de chaque ordi et les données sur le réseau ?

---

La réponse est contenue dans la question... ;)

Mais ton problème ne doit pas venir de là...

Argy

Effectivement, c'est ce que j'ai fait. ça ralenti la chose mais je pense que c'est plus stable comme ça... Reste ce problème d'export excel pour lequel je ne vois vraiment pas comment faire... :(

Quelqu'un aurait une idée ?

Je t'ai donné la solution...
Pose un

Code:

---

On Error Goto

---

et passe en mode simulation de Runtime sur ton poste : soit ton fichier en accdr.
Si pas d'erreur, essaye avec le même procédé sur ta version réseau.

Récupère l'erreur s'il y a et communique-la.
A mon avis, tu auras une erreur 1004 quelque part ou bien 462.
Juste une histoire de qualification d'objet.

Argy

J'ai voulu essayé ta technique, Argy.

Malheureusement (et c'est aussi ça le bogue), en changeant dans la procédure d'export Excel, le bogue a disparu. Du coup, pas moyen de connaître l'erreur...

Mais je me suis rendu compte qu'il y avait un autre bogue, du fait de l'utilisation du shell (j'avais utilisé le code que tu m'avais conseillé).

En effet, pour afficher le fichier Excel, et étant donné qu'il y avait des espaces dans le chemin d'accès, j'ai utilisé une fonction que j'avais trouvé sur le net qui marche très bien :
En début de module, je mettai :

Code:

---

1 2 3 4 5 6 7 8 9 10

Private Declare Function GetShortPathName Lib "kernel32" Alias "GetShortPathNameA" (ByVal lpszLongPath As String, ByVal lpszShortPath As String, ByVal lBuffer As Long) As Long   Function GetShortName(LongPath As String) As String Dim LenShortName As Long Dim buffer As String * 1000 LenShortName = GetShortPathName(LongPath, buffer, Len(LongPath)) If LenShortName Then GetShortName = Left$(buffer, LenShortName) End If End Function

---

Et à la fin de ma procédure, si la personne demandait à voir le fichier, je mettai :
'Dossier_Bureau indique le chemin d'accès du bureau
'srtXLFileName est le nom du fichier excel

Code:

---

dblShell = Shell("EXCEL.EXE " & GetShortName(Dossier_Bureau & "\" & strXLFileName), 3)

---

La version complète gérait très bien cela, pas la version runtime (erreur n°53 : fichier introuvable). Du coup, j'ai mis ce code :

Code:

---

1 2 3 4

Set xlApp = CreateObject("Excel.Application") xlApp.Workbooks.Open Dossier_Bureau & "\" & strXLFileName xlApp.Visible = True Set xlApp = Nothing

---

L'idée étant que j'ai fermé l'objet xlapp et, ensuite, je le recréée si la personne veut voir le fichier.

Argy, tu m'avais dit que cette façon de faire fragilisait le système. Mais je ne vois pas comment faire pour utiliser le shell de façon à ce qu'il gère les espaces dans le chemin d'accès. Mais si tu as une meilleure solution...

Humm, un Shell devant ouvrir un fichier pourvu d'espaces doit être entouré de «».
Soit :

Code:

---

dblSuccess=Shell("EXCEL.EXE " & Chr(34) & strFileName & Chr(34), 1)

---

où strFileName est le nom complet de ton fichier.

Get getShortPathName() ne résoudra pas ton problème ; cette API a été mise en place pour la compatibilité 16/32 en format DOS 8.3.

Argy

P.S. dblSuccess te renvoie le PID de ton instance Excel. Dans le gestionnaire de tâche, tu le retrouveras (si tu as affiché la colonne idoine)

Merci pour tes explications, Argy.

J'ai essayé ton code et, malheureusement, ça ne fonctionne pas. Il génère une erreur lors de l'ouverture du fichier Excel. Erreur n°53 : fichier introuvable

Du coup, pour l'instant, je garde l'ancienne méthode d'ouvrir le fichier excel avec

Code:

---

1 2 3 4

Set xlApp = CreateObject("Excel.Application") xlApp.Workbooks.Open Dossier_Bureau & "\" & strXLFileName xlApp.Visible = True Set xlApp = Nothing

---

Je sais que c'est pas terrible (risque d'instabilité) mais à défaut de mieux...

Ce n'est pas normal que ça ne marche pas.
Tu as une boulette dans ton code...

Quelle est la valeur de Dossier_Bureau & "\" & strXLFileName ?


Argy

Encore une fois, c'est un souci de Runtime, mais le vrai Runtime. J'ai essayé avec la version complète, pas de pb, avec une version où j'avais renommé en .accdr pour avoir un runtime, pas de problème.
Mais quand je passe au PC qui n'a que le runtime (les deux PC sont sous Windows 7), ça ne marche pas.

Dossier_Bureau = d:\Utilisateurs\mpub\Desktop
strXlFileName = MP F1154.xlsx

A moins que ça vienne du fait que la personne qui gère mon PC a mit le profil utilisateur sur une partition (D) au lieu de la laisser sur C ???


Voilà, si tu as une idée...

Citation:

---

...le profil utilisateur sur une partition (D) au lieu de la laisser sur C ???

---

Humm...
Je ne comprends rien à ton histoire... :? :)
Bon, il faut que tu reprennes tout depuis le début :
Tu prends ta variable strXLFileName
Tu lui affectes la valeur du fichier Classeur à créer quelque soit le chemin cible ; si Mes documents sont sur C:\ ou D:\ ou K:\, qu'importes, il t'appartient de récupérer cette valeur selon et non de la coder en dur !!!
Par exemple :

Code:

---

strChemin= CheminCible()

---

avec la fonction :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Function CheminCible() As String Dim straBureau(1 To 2) As String Dim strChemin As String Dim C As Integer straBureau(1) = "Bureau\" straBureau(2) = "Desktop\" For C = 1 To 2 strChemin = Environ("USERPROFILE") & "\" & straBureau(C) If Len(Dir(strChemin, vbDirectory)) Then Exit For End If Next CheminCible = strChemin End Function

---

Donc ton nom de fichier sera :

Code:

---

strXLFileName = strChemin & "\" & "MP F1154.xlsx"

---

Tu sauves ton classeur...
Et là seulement, tu peux balancer un Shell...

Code:

---

dblSuccess=Shell("EXCEL.EXE " & Chr(34) & strXLFileName & Chr(34), 1)

---

Il n'y aucune raison pour que ça ne marche pas et comme je te l'ai dit, même si le App.Visible = True marche sur la version complète, je te conseille vivement d'oublier cette solution (rustine)...

Argy

Eh bien, malgré tous tes efforts (je te remercie d'ailleurs !), ça ne marche pas sur la version Runtime alors que c'est sans problème sur la version compplète et même sur une version en .accdr...

Donc, pour l'instant, je me contente de la rustine (app.visible = True).

Une nouvelle idée ? :?

Est-ce que le dossier
d:\Utilisateurs\mpub\Desktop
existe sur le poste en question ?

Argy

Oui ce dossier existe bien.

Par ailleurs, je n'ai jamais coder en dur mais en relatif. J'avais écrit un bout de code avec HOMEPATH et HOMEDRIVE pour trouver le chemin du bureau.
J'ai changé de méthode en utilisant ton code. Et malheureusement, ça ne marche pas...

Plus exactement, il repère bien que le chemin existe puisqu'il arrive à créer le fichier Excel à cet endroit. C'est pour la méthode Shell qu'il n'arrive pas à trouver le chemin. Alors que j'ai bien fait tout comme t'avais dit...

Humm, OK donc c'est qu'il ne trouve pas Excel... comme il se doit alors.
Tu me mets le doute :mouarf:

Bref, essaye cette nouvelle option :

Code:

---

1 2 3 4 5 6 7 8 9 10

Private Declare Function FindExecutable Lib "shell32.dll" Alias "FindExecutableA" (ByVal lpFile As String, ByVal lpDirectory As String, ByVal lpResult As String) As Long   Public Function GetExcelPath(ByVal Filename As String) As String Dim strBuffer As String strBuffer = String(260, 32) If FindExecutable(Filename, vbNullString, strBuffer) > 32 Then GetExcelPath = Left$(strBuffer, InStr(strBuffer, vbNullChar) - 1) End If End Function

---

Ca doit te renvoyer quelque chose comme :
C:\Program Files\Microsoft Office\OFFICE11\EXCEL.EXE
Ensuite tu modifies le Shell comme suit :
D'abord sur ton poste (version complète) et ensuite sur le Runtime...

Code:

---

1 2	dblSuccess=Shell(Chr(34) & GetExcelPath(strXLFileName) & Chr(34) & " " & Chr(34) & strXLFileName & Chr(34), 1) MsgBox "Résultat du Shell : "& dblSuccess, ,"Test"

---

Argy