[AC-2007] Export d'Access vers Excel en utilisant Access Runtime 2007

[Humanisto]

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...

[Philippe JOCHMANS]

Bonjour

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

Philippe

[Humanisto]

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

[nico84]

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...

[argyronet]

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

[Humanisto]

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

[Humanisto]

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 ?

[argyronet]

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

[Humanisto]

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 ?

[argyronet]

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

[Humanisto]

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...

[argyronet]

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)

[Humanisto]

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...

[argyronet]

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

[Humanisto]

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...

[argyronet]

...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

[Humanisto]

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 ?

[argyronet]

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

Argy

[Humanisto]

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...

[argyronet]

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

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