Discussion :

[fred78stz]

Bonjour à tous,

Pour expliquer mon projet, je travaille un peu en urgence pour aider le service MPA (matériel pédagogique adapté) au sein de l'ASH, service départemental de l'éducation nationale chargé de prêter des ordinateurs pour des élèves handicapés scolarisés en classes ordinaires ou en ULIS. Il s'agit du contexte. Pour expliquer l'historique, la personne qui gérait le matériel avait bricolé des tableaux EXCEL qui sont devenus inutilisables en raison du nombre croissant de matériel dans notre département. J'ai donc pensé à ACCESS pour avoir travaillé avec cet outil en 2000.

ci-dessous les relations entre les tables :


Ma problématique est la suivante : il s'agit de faire des formulaires pour les emprunts (table_emprunts) et un formulaire croisant la table élèves, établissement et ERS (enseignants référents de scolarisation). Je sollicite votre aide étant un peu pressé par le temps et ayant aussi besoin de réactualiser mes connaissances sur le sujet. De plus si vous pensez que la structure de mes tables peut être améliorée je suis preneur
Le but étant de permettre la gestion du stock de matériel et l'attribution aux élèves, puis une gestion par état des conventions de prêt.

Bien à vous,

Frédéric

[marot_r]

Bonjour.

Ta structure parait pas mal pour répondre à tes spécifications.

Les deux tables seuls sans relation sont un peu étonnantes mais celle qui me semble étrange c'est ta table des retours.
Tu peux avoir des retours sans emprunt ?
Si non, à mon avis, la date de retour devrait être dans la table des emprunts.
Si oui, même là, je pense qu'il serait plus facile d'avoir un retour dans la tables des emprunt sans les autres informations.
Je te suggère de créer un index unique composé de l'identifiant de l'élève, celui de la machine et de la date d'emprunt. (un élève peut emprunter plusieurs fois la même machine).

Tu peux aussi voir à supprimer l'identifiant de l'établissement car tu peux le déduire de l'identifiant de l'élève qui lui-même est rattaché à un établissement.
Personnellement je le garderai, même si c'est une violation de la décomposition en 3ième forme normale, mais il faudra le gérer au niveau des écrans de saisie pour qu'il "suive" le mouvement.
Si tu as peux de mobilité d'étudiant, c'est assez facile à gérer.
L'avantage de la garder est qu'il est facile d'avoir la liste des emprunts d'un établissement directement à partir de la table des emprunts.

Un dernier point, il existe sans doute sur le marchés de logiciels tout fait qui font de la gestion de prêt, les as-tu considéré ?

Les avantages sont que :

1. Tu peux l'avoir généralement tout de suite.
   Développer une application même simple peut être un travail de longue haleine.
2. Si il y a des modifications ou des mises à jour, du support aux usagers, des réparations suite à une panne, c'est ton fournisseur qui s'en occupe avec une équipe de professionnels dont c'est le travail et pas toi sur ton temps de loisir ou en grugeant sur tes autres activités.

L'inconvénient est que c'est rarement EXACTEMENT ce dont tu as besoin mais les compromis peuvent être minimes.

Dernier point n'oublie pas que si tu as plusieurs utilisateurs ils doivent pouvoir accéder à un répertoire commun sur ton réseau.
Les accès via Internet sont possibles mais loin d'être simples.

A+

[fred78stz]

Bonjour.

Ta structure parait pas mal pour répondre à tes spécifications.

Les deux tables seuls sans relation sont un peu étonnantes mais celle qui me semble étrange c'est ta table des retours.
Tu peux avoir des retours sans emprunt ?
Si non, à mon avis, la date de retour devrait être dans la table des emprunts.
Si oui, même là, je pense qu'il serait plus facile d'avoir un retour dans la tables des emprunt sans les autres informations.
Je te suggère de créer un index unique composé de l'identifiant de l'élève, celui de la machine et de la date d'emprunt. (un élève peut emprunter plusieurs fois la même machine).

Tu peux aussi voir à supprimer l'identifiant de l'établissement car tu peux le déduire de l'identifiant de l'élève qui lui-même est rattaché à un établissement.
Personnellement je le garderai, même si c'est une violation de la décomposition en 3ième forme normale, mais il faudra le gérer au niveau des écrans de saisie pour qu'il "suive" le mouvement.
Si tu as peux de mobilité d'étudiant, c'est assez facile à gérer.
L'avantage de la garder est qu'il est facile d'avoir la liste des emprunts d'un établissement directement à partir de la table des emprunts.

Un dernier point, il existe sans doute sur le marchés de logiciels tout fait qui font de la gestion de prêt, les as-tu considéré ?

Les avantages sont que :

1. Tu peux l'avoir généralement tout de suite.
   Développer une application même simple peut être un travail de longue haleine.
2. Si il y a des modifications ou des mises à jour, du support aux usagers, des réparations suite à une panne, c'est ton fournisseur qui s'en occupe avec une équipe de professionnels dont c'est le travail et pas toi sur ton temps de loisir ou en grugeant sur tes autres activités.

L'inconvénient est que c'est rarement EXACTEMENT ce dont tu as besoin mais les compromis peuvent être minimes.

Dernier point n'oublie pas que si tu as plusieurs utilisateurs ils doivent pouvoir accéder à un répertoire commun sur ton réseau.
Les accès via Internet sont possibles mais loin d'être simples.

A+

Merci beaucoup pour ta réponse !

Effectivement il y a des modifications à faire et effectivement intégrer les retours dans la table des emprunts, je vais faire ça.
Il y a des solutions prêtes à l'emploi, j'ai pas mal chercher sur le sujet. Mais là c'est un coup d'essai et un dépannage en urgence
la personne qui a pris le poste pour la gestion du matériel a récupéré un outil EXCEL truffé d'erreurs et de lacune, conclusion une
grande part du matériel doit être dans la nature...

De plus, ce projet en englobera certainement un autre que je vais modéliser bientôt. Je reviendrai certainement vers vous pour quelques
conseils au besoin.
Merci encore !

Frédéric

[fred78stz]

Je poursuis la discussion car j'ai mis en place un module dans Outlook qui permet de récupérer des pièces jointes pour les verser dans un dossier "MPA" sur un disque réseau
à mon travail. Jusque là pas de problème cela fonctionne sans problème.
Là où je sèche, c'est sur la partie du code pour récupérer des valeurs dans les champs de formulaire WORD. J'ai trouvé un code sur un tuto (très bien fait) :
http://heureuxoli.developpez.com/office/sondage/

La première partie du module passe sans problème :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Sub ReucpFichier()
Dim oFSO As New FileSystemObject
Dim oFil As File
Dim oFold As Folder
 
Set oFold = oFSO.GetFolder("C:\Temp\sondage\")
 
For Each oFil In oFold.Files
    If Right(oFil.Name, 4) = "docm" Then
        Extract (oFil.Name)
        oFil.Move "C:\temp\sondage\done\"
    End If
Next oFil
 
Set oFSO = Nothing
 
End Sub

C'est sur la méthode Public Function Extract que le bas blesse. Voilà le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
Public Function Extract(oFN As String)
On Error Resume Next
Dim wApp As New Word.Application
Dim oDoc As Word.Document
Dim rs As DAO.Recordset
Dim sql As String
Dim i As Integer, j As Integer
 
 
Set oDoc = wApp.Documents.Open(FileName:="C:\temp\sondage\" & oFN)
 
oDoc.Unprotect
 
i = oDoc.FormFields.Count
Debug.Print i
Set rs = CurrentDb.OpenRecordset("tbl_sondage", dbOpenTable)
    'édition du jeu d'enregistrement par ajout
    rs.AddNew
    For j = 1 To i
        rs.Fields(j) = oDoc.FormFields(j).Result
 
    Next j
    rs.Fields(j + 1) = oFN
    rs.Update
oDoc.Close SaveChanges:=False
rs.Close
Set rs = Nothing
Set oDoc = Nothing
wApp.Quit
 
End Function

Je pense qu'il s'agit plutôt d'un problème de référence. J'ai intégré les références DAO dans ACCESS. Mais peut-être ai-je oublié une référence ?
Le code me paraît ok. QU'en pensez-vous ?

Frédéric

[marot_r]

Bonjour.

C'est sur la méthode Public Function Extract que le bât blesse. Voilà le code :

Je soupçonne que c'est parce qu'il te faut une référence sur Word pour les lignes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Dim wApp As New Word.Application
Dim oDoc As Word.Document

mais il faudrait préciser là où tu as l'erreur et quel est le message.

A+

[fred78stz]

C'est exactement cela. Merci pour ta réponse. J'ai inclus la référence Microsoft Word et le message d'erreur disparaît.
Il demeure que l'importation des champs avec l'index ne fonctionne pas. Peut-être changer les index par les noms de champs
serait plus judicieux^^ ?

A+

Frédéric

[marot_r]

Personnellement quand je peux j'utilise des noms car les indexes sont trop susceptibles de changer, ceci dit parfois c'est la meilleurs solution.

Je n'ai pas exécuter ton code donc difficile de savoir pourquoi cela ne marche pas.
Je t'invite à utiliser le mode pas à pas et de suivre ton programme à la trace.
Tu auras peut-être une piste d'explication.

1. Est-ce que je ne lis pas les données ?
2. Est-ce que je lis les données mais ce ne sont pas les bonnes ?
3. Est-ce que j'ai une erreur qu'Access ne signale pas qui fait que mon code ne s'exécute pas.

A+