Discussion :

[Vitaliq]

Bonjour,

Je suis responsable de la maintenance dans une petite boite d'audiovisuel, j'aimerai mettre en place une base de donnée pour la gestion de la maintenance (suivi des interventions en cours, état, historique, générer des documents, du reporting). J'ai donc commencé ma modélisation mais je bloque sur un sujet depuis un petit moment. Voici ce que ça donne.



Nous travaillons par affaire (je veux que ma base soit plus ou moins greffable avec l'erp DIVALTO qu'ils utilisent dans les bureaux donc je garde cette architecture), ainsi un équipement est lié à une et une seule affaire.



Mon but est donc de pouvoir créer des "tickets" de maintenance liés à un matériel, ce ticket contiendra une sous table pour avoir un historique



Ici ça marche bien pour les projecteurs mais j'ai un parc de machine assez diversifié (projecteurs, PC, tracking...) j'aimerai me laisser la possibilité de créer de futures tables pour les autres types (qui portent des informations bien différentes) mais je ne sais pas comment le gérer ? Et j'aimerai qu'un ticket "incident" puisse concerner plusieurs types de matos (Par exemple un incident peux concerner 1 PC et 3 projecteurs).

Est-ce que je m'y suis bien pris jusqu'à présent ?


Par la suite j'aimerai pouvoir partager la base sur sharepoint ( nous avons déjà un site sharepoint mais je n'y ai pas toujours accès lorsque je suis en intervention aux 4 coins de l'europe par exemple ), pensez-vous cela possible ?

Merci d'avance.

[marot_r]

Bonjour.

Tu as 3 possibilités :

• 
  
  • Une table de type qui identifie les types de matériel.
  • Une table Commune qui regroupe les informations commune à tout tes appareil (ex : NoSerie, Nom, Type) avec un indicateur de type de matériel.
  • Une table par type de matériel ou tu enregistres les informations spécifiques de ce type de matériel (ex : Diagonal, Résolution).
• 
  
  • Une table de type qui identifie les types de matériel.
  • Une table Commune qui regroupe les informations commune à tous tes appareils (ex : NoSerie, Nom, Type) avec un indicateur de type de matériel.
  • Une table des caractéristiques possible pour tous les appareils (ex Résolution).
    On gagnera sans doute a avoir un indicateur de type de matériel pour s'y retrouver plus facilement dans les caractéristiques.
  • Une table d'association qui associe le matériel à sa caractéristique.
  
  Cela ressemble à la fenêtre propriété des contrôles. Tous les contrôles en ont une mais la liste des propriétés varie pour chaque type de contrôle.
  C'est très souple, tu peux quasiment ajouter n'importe quel type de matériel SANS avoir a changer la structure de la BD.
  Il y aura aussi sans doute peu d'impacts sur l'interface elle-même.
  Cette solution peut être pénible si tu veux faire un tableau qui présente en colonnes côte à côte tes caractéristiques.
• 
  
  • Une table de type qui identifie les types de matériel.
  • Une seule table pour tous les types.
    Donc une table, tous les champs dont tu as besoin pour tous les types d'appareil.
  • C'est seulement à l'affichage que va faire la différence, soit avec un formulaire qui affiche ou cache ses contrôles selon le type ou avec un formulaire par type.
  
  Si ce n'est pas la plus élégante, cette solution est la plus simple à vivre.
  Évidement ne pas oublier la limite de 255 champs dans une table.

A+

[Vitaliq]

Merci pour votre réponse, désolé j'étais en déplacement je n'ai pas eu le temps de me pencher à nouveau sur le sujet, là je vais avoir du temps les prochaines jours après avoir bien regardé les 3 solutions et compte tenu mes compétences restreintes en modélisation de BDD je vais opter pour la 3ème.

En revanche je me demande du coup à quoi sert la table de type ? Ne peut-on pas simplement ajouter un champ "Type" dans la table fourre tout qui permettra de faire le tri dans les requêtes et formulaires ?

Effectivement ce n'est pas la solution la plus élégante mais le but est de me faire gagner du temps sur la recherche d'information et la création de rapports (marre de chercher dans 15 excel sur 12 dossiers partagés... ah nan ce fichier là était était sur le disque dur externe d'un collègue !).

Maintenant je ne sais pas comment gérer les options configurables de mes matériels, par exemple les lampes ou optiques des projecteurs ou les cartes graphiques des PC, qui sont des informations importantes pour nous. Je dois pouvoir en un coup d'oeil ce que contient telle ou telle installation, ce qui me fait gagner du temps pour trouver l'origine du dysfonctionnement.

[marot_r]

Bonjour.

L'utilisation d'une table des Type évite que tu te retrouver avec "FOURCHETTE" comme type d'équipement.
Seuls les types référencés seront acceptés lors de la saisie.
Ce n'est pas forcément indispensable mais c'est généralement une bonne idée surtout quand on a du code qui teste les types.

Maintenant je ne sais pas comment gérer les options configurables de mes matériels, par exemple les lampes ou optiques des projecteurs ou les cartes graphiques des PC, qui sont des informations importantes pour nous. Je dois pouvoir en un coup d'oeil ce que contient telle ou telle installation, ce qui me fait gagner du temps pour trouver l'origine du dysfonctionnement.

Comme tu as tout dans une seule table, tu as juste à renseigner les champs voulus.
Tu peux faire :

• 1 formulaire par type de matériel
• ou 1 formulaire unique où tu caches ou affiches les champs qui t'intéressent selon le type.
  Si tu n'as pas trop de "trous" où si les trous sont "logiquement" groupés, c'est la meilleur solution d'après moi.
  Quelque chose comme :
  
  

  Code :

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

  1
  2
  3
   
  Ecran                     |Projecteur
  Renseignements pour Écran |Renseignements pour projecteur

  Les "Colonnes" sont remplies ou pas selon le type.
  Cela donne l'illusion que ton écran plusieurs sources mais en réalité ce n'est pas le cas.

A+

[Vitaliq]

D'accord je comprends.

En revanche je peux avoir jusqu'à 6 lampes par projecteur, Entre 4 et 5 cartes d'acquisition, 2 cartes graphique par PC etc. donc ça va être assez lourd à gérer.

Je pense revenir sur une de tes premières solutions.

[Vitaliq]

Voilà j'ai modifié en suivant votre solution n°1 cette fois ci



Cela semble marcher pour des exemples simples, la base vous parait-elle suffisamment robuste et pas trop alambiquées pour lorsque je vais passer aux requêtes et formulaires ?


Peut-on verrouiller dans la structure même de la base pour qu'on ne puisse entrer des "caractéristiques de projecteur" QUE pour les matériels de type projecteur ?

[marot_r]

Bonjour.

la base vous parait-elle suffisamment robuste et pas trop alambiquées pour lorsque je vais passer aux requêtes et formulaires ?

J'aime bien ton modèle et je serais sans doute arrivé à quelque chose de semblable.
Évidement tu vas avoir pas mal de requêtes et d'écran spécifiques mais la partie "commune" me paraît assez vaste pour les requêtes courantes du type : "Donne moi la liste de mes équipements".
Si tu as besoin d'un nouveau type d'équipement il te faudra créer de nouvelles tables pour ses attributs.
Et il est très probable qu'il y a des détails qui manquent que tu découvriras au fur et à mesure de ta programmation. Il est rare d'avoir un modèle parfait dés la conception.

J'ai juste quelques remarques :

• Pour les noms internes, se limiter aux chiffres, aux lettres majuscules et minuscules non accentuées et non "décorée" (pas de ç), et au souligné (_).
  Pas de tiret (-), d'espaces ( ) et caractères non alphabétiques.
  Même si Access est très (TROP) tolèrent pour les noms, cela peut être source de bugs particulièrement vicieux et sournois, spécialement si tu prévois de faire de l'échange de données avec d'autres systèmes.
  Si tu as besoin de texte plus agréable pour les humains utilise des étiquettes dans des formulaires. Elles sont là pour cela.
  
• À propos des champs pièces jointes.
  Je ne sais pas si ce sont de vrai champs où tu peux mettre un fichier ou des champs multi-valués.
  Si ce sont des champs pour mettre des fichiers, comme Access est limité à 2 Go, il est préférable de ne stocker QUE le chemin d'accès dans un champ texte et de faire du code pour ouvrir les fichiers.
  Deplus ressortir le document de Access semble pas mal galère.
  Si ce sont des champs multi-valués, je te recommanderai de faire une table à part au lieu d'une table incluse dans le champ. Les outils d'Access marchent mieux avec cette architecture.
  
• Tu voudras peut-être ajouter des tables de référence pour les modèles de tes différents équipement.
  
• J'ajouterai le Type en plus du numéro de série pour les relations, et peut-être la marque. Il est improbable mais pas impossible que 2 constructeurs donne le même numéro de série à leur équipement.
  Accessoirement cela peut aussi aider à la sélection sans avoir à repasser par la table équipement.

Peut-on verrouiller dans la structure même de la base pour qu'on ne puisse entrer des "caractéristiques de projecteur" QUE pour les matériels de type projecteur ?

Tu ne peut pas en tant que tel mais comme tes caractéristiques d'écran sont dans leur propre table cela ne devrait pas poser de problème.
Quand ton utilisateur va entrer un écran il sera sur un formulaire dédié aux écrans où tu pourras ne lui présenter que les caractéristiques qui t'intéressent.

Si tu as des caractéristiques mutualisées tu peux toujours leur associer un type de matériel.

A+

[Vitaliq]

Merci pour ces précisions

Oui c'est vrai j'ai pas été très rigoureux au niveau des noms, pourtant c'est la base que je suis sensé avoir appris dans le peu de cours sur les bdd que j'ai fait

Pour les champs multi-valués et les PJ c'est juste le format de base des tables pré-remplies d'access. Je vais effectivement mettre des liens vers des dossiers. Afin de planifier au mieux la mise en ligne de la base je me demande si les sauvegardes de liens doivent être sur un local ou sur le dossier partagé.

En effet lorsque je suis en intervention je n'ai pas toujours accès au web ou au réseau (via VPN) je suis donc en local sur mon laptop et je vais rentrer/lire des données pendant les interventions, une fois sur le réseau il faudra donc synchroniser la base (via sharepoint, access web, un batch je ne sais pas encore). Je suppose que des solutions existent.

Pour les nouveaux types de matériel je ne sais pas encore si je vais ajouter tout manuellement au fur et à mesure, je sais qu'on peut faire un formulaire de création de table mais je ne sais pas si on peut gérer les relations, ça risque d'être beaucoup de boulot pour peu d'ajouts au final (on ne va pas ajouter des types tous les jours)

En effet je serai créateur, gestionnaire et utilisateur (+d'autres personnes évidemment) de la base c'est assez délicat (mais j'aurais pas l'excuse de dire "putain mais qui est le c** qui a conçu ça" )

Je laisse le sujet ouvert j'aurais surement d'autres difficultés.

[marot_r]

Bonjour.

En effet lorsque je suis en intervention je n'ai pas toujours accès au web ou au réseau (via VPN) je suis donc en local sur mon laptop et je vais rentrer/lire des données pendant les interventions, une fois sur le réseau il faudra donc synchroniser la base (via sharepoint, access web, un batch je ne sais pas encore). Je suppose que des solutions existent.

Attention c'est un point TRÈS important car si il existe des possibilités elles ne sont pas forcément simples.
Cela peut même conditionner la façon dont tu vas concevoir tes tables !
Access est clairement conçu pour marcher avec un environnement fixe.

L'important là c'est de savoir si tu as un vrai partage de données c-à-d que les personnes qui sont à des places différentes modifient les mêmes données en même temps ou si tu n'as qu'un partage partiel.
Dans un partage partiel, un des 2 groupes d'utilisateur ne "touche" pas au données de l'autre. Par exemple, certaines personnes ne sont qu'en lecture sur tout ou partie des données ou alors une fois les données entrées, leur auteur n'y revient pas quand il est déconnecté.

Pour des raisons de simplicité, une solution qui te donne un accès distance à ton application qui t'évite d'avoir à mettre en place une synchronisation est fortement recommandée.
J'ai un ami qui utilisait LogMeIn pour se connecter à son PC via son téléphone cellulaire ce qui lui donnait accès à son application en tout temps sans aucune modification à part un écran de saisie spécifique adapté pour l'écran de son téléphone.
Ajuster la disposition et la taille d'un formulaire est vraiment plus simple que de mettre en place un mécanisme se synchro.

A+

[Vitaliq]

Nous avons un site sharepoint (que nous le service technique on utilise quasiment pas) donc j'avais cru comprendre qu'on pouvait publier assez facilement une base access sur sharepoint ainsi que les requêtes et formulaires.

Ceux ayant juste besoin de consulter les données pourront utiliser les vues access tandis que ceux qui ont besoin de modifier les données utiliseront access. Il me semble même avoir lu qu'on pouvait modifier des données dans sharepoint sans tout compromettre mais je ne pourrai confirmer.

Effectivement ça me semble être source de conflit potentiels mais je ne pense pas que ça puisse être pire que l'état actuel (néant, tout en local sur des fichiers excel qui se perdent).

[marot_r]

Si tu prévois une base Web, il faut la concevoir dés le début comme une base Web.
Il y a pas mal de contraintes et en gros cela n'a d'Access que le nom.

Fait des recherches sur le sujet avant de te lancer plus avant dans ton développement.

A+

[marot_r]

Et en plus les versions Web de Access ne sont pas rétro-compatible.
Si tu change de version, il faut réécrire ton appli.
Fait vraiment des recherches poussées sur le sujet avant de plonger.

A+

[Vitaliq]

Ok laissons tomber le web, de toute façon je n'aime pas particulièrement sharepoint, je trouve ça hyper lourd.

Une bonne solution semble être de fractionner la base, je me renseigne encore dessus mais cela permettrait d'avoir la base dorsale sur le disque partagé et que chaque utilisateur possède la base frontale.

Reste à voir si on peut travailler en local sur la frontale (au moins en lecture). Je vais faire des tests. Il faut aussi que je vérifie si des utilisateurs peuvent accéder aux données (en lecture au moins) avec access runtime. A cause du passage à access 365 tout le monde n'a pas access sur son PC et de licence.

Sinon le VPN pour acceder via internet au disque partagé.

Vu le nombre réduit d'utilisateurs je ne pense pas qu'il y a trop de risque de conflits.

[marot_r]

Bonjour.

Quand tu es en mode fractionné.

Ta frontale sert uniquement pour la partie interface et logique, elle ne contient pas de données.
Ta dorsale est là où sont les données.
Donc une frontale sans connexion à ses données ne sert absolument à rien et n'est pas fonctionnelle.

A+

[Vitaliq]

D'accord je pensais qu'il y avait tout de même moyen d'avoir un cache.

[marot_r]

Non, malheureusement non.

Je crois que si on utilise Azure (le SQL Server Cloud de M$) il y a une possibilité de travailler en mode déconnecté et que la BD se charge des syncho mais je n'ai jamais creusé le sujet.
Le principe c'est une frontale en Access et une dorsale en MS SQL Server.

A+

[Vitaliq]

Dans tous les cas ça demande des compétences que je n'ai pas j'ai l'impression (et longues à acquérir).

Je vais surement laisser la base entière et corriger les éventuels problèmes à l'usage puis la fractionner une fois satisfaisant. Et pour le local ça se fera sur des extractions avant de partir sur site (si on y pense !).

[Vitaliq]

J'ai un soucis avec mon formulaire, j'ai une liste qui me permet de sélectionner mes enregistrements pour y ajouter ses contacts (puis ses affaires ensuite).

J'aimerai pouvoir via ce formulaire créer un nouvel enregistrement, j'ai essayé de créer un bouton avec la macro "nouvel enregistrement" mais cela ne marche pas.

L'idéal serait via la combobox de pouvoir taper le nouveau "client" et que si il ne fait pas partie de la liste il en créé un nouveau enregistrement.



Je suppose que cela se situe dans une des conditions ci-dessous (si modification) mais je n'arrive pas à lui faire créer un nouvel enregistrement qui prendrais le nom de ce qu'on saisi (je rajouterai ensuite un msgbox du type "nouvel enregistrement créé" pour prévenir qu'on créer une nouvelle entrée.

[Vitaliq]

Bon j'ai avancé un peu sur mon formulaire mais je n'arrive toujours pas à ajouter un enregistrement via la combobox. J'ai l'impression que l’événement NotInList ne marche pas avec une liste issue d'une table.

Voici ce que j'ai, ça fait un peu usine à gaz.

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
32
33
34
35
36
Private Sub Client_NotInList(NewData As String, Response As Integer)
 
   Dim dbsClient As DAO.Database
   Dim rstID_Client As DAO.Recordset
   Dim intAnswer As Integer
 
On Error GoTo ErrorHandler
 
   intAnswer = MsgBox("Ajouter " & NewData & " a la liste des clients ?", _
      vbQuestion + vbYesNo)
 
   If intAnswer = vbYes Then
 
      Set dbsClient = CurrentDb
      Set rstID_Client = dbsClient.OpenRecordset("Client", dbOpenTable)
      rstID_Client.AddNew
      rstID_Client.Fields("ID client").Value = NewData
      rstID_Client.Update
 
      Response = acDataErrAdded
   Else
      Response = acDataErrDisplay
   End If
 
   rstID_Client.Close
   dbsClient.Close
 
   Set dbsClient = Nothing
   Set rstID_Client = Nothing
   Me.Refresh
 
ErrorHandler:
   MsgBox "Error #: " & Err.Number & vbCrLf & vbCrLf & Err.Description
 
 
End Sub

En revanche j'arrive à créer de nouveaux elements avec un bouton et une msgbox mais dans ce cas je n'arrive pas à mettre le focus sur le nouvel enregistrement après création (comme montre les exemples sous commentaires).

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
Private Sub Ajout_client_Click()
 
Dim new_client As String
Dim oRst As DAO.Recordset
Dim oDb As DAO.Database
 
 
new_client = InputBox("Saisir nom client", "création nouveau client")
 
Set oDb = CurrentDb
Set oRst = oDb.OpenRecordset("Client", dbOpenTable)
'Passe en mode Ajout
oRst.AddNew
'Affecte les différents champs
oRst.Fields("ID client").Value = new_client
 
 
'Met à Jour
oRst.Update
Me.Refresh
'Me.creation_client.SetFocus
 
'Me.Form!Client.SetFocus
'DoCmd.GoToRecord acDataTable, "Client", acGoTo, new_client
 
End Sub

[Vitaliq]

J'ai un soucis avec un autre formulaire.

J'ai un formulaire contenant mes différentes installations (affaires)

De là j'ai un sous formulaire permettant de lister tous les matériels d'une installation.

Ensuite j'ai un sous formulaire "caractéristique du ****" et je j'aimerais que ce sous formulaire imbriqué caractéristique soit fonction de ma liste déroulante "type"; par exemple si je sélectionne PC, ce soit le formulaire carac_PC qui est affiché etc.