Bonjour,
Pierre Fauconnier m'a aimablement avisé.
P.
Version imprimable
Bonjour,
Pierre Fauconnier m'a aimablement avisé.
P.
Bonjour Pierre(S),
oui j'ai été dérouté plusieurs fois, mais il est vrai que je n'était pas le demandeur.
merci.
Normalement, vous retrouvez la discussion dans vos discussions suivies ou votre tableau de bord, que la discussion ait été déplacée ou pas. C'est +/- transparent pour les utilisateurs, sauf pour le posteur initial qui reçoit l'info.
et en plus le déplacement dans office est logique,c'est pas par hasard que tu as fais ce choix, il regroupe les compétences Excel et Access car là ou nous en somme on peut dire que ce n'est pas figé.
bonjour,
exact , il est possible en effet ,
qu'après étude sur acces on repasse sur excel (vue la taille mini des tables) ,
et excel est plus accessible à l'imagination / création et surtout pour la sortie graphique !! ;)
@+JP
Mwouais... Excel n'est pas un Access Lite
j'abonde dans le sans de Pierre Fauconnier, j'ai déclaré plus haut qu'il était préférable de tout gérer dans Access et là à la tournure de la discussion je confirme.
on peut faire des requêtes de sélection avec jointure entre tables, alors que dans Excel on parcours les ligne et les onglets d'un classeur.
Normalement:
- on gère les données dans Access (manipulations CRUD et états (listings de données));
- on prépare les requêtes d'analyse XL dans Access (puisqu'on a la main sur Access);
- on lie les données dans Excel;
- on analyse dans Excel (TCD, graphiques, ...) sur bases de requêtes d'analyse Access;
On n'analyse pas dans Access, et certainement pas avec les TCD/Graphiques d'Access qui sont mer****** par rapport aux outils Excel.
De.plus,fait non négligeable,Access dispose d'un assistant de conception pour toutes ces chose.
Bien que les formulaires que j'ai créé soit visuellement ca ca c'est l'assistant qui les a gérés je n'est absolument rien fait.
Je suis d'accord sur les atouts respectifs d'Excel et d'Access mais le souci, c'est que mon Access est un vieux tacot 1997-2000 qui ne reconnaît pas tes fichiers, Robert ! Et on ne trouve plus Access séparément dans le commerce; il n'existe plus que dans la suite 365. Sacré cul-de-sac. Y a-t-il un marché parallèle pour les softs ?
Bien à vous
Pierre
On peut acheter Access 2016 indépendamment de la suite Office: https://www.microsoft.com/fr-be/stor...%3aoverviewtab ;)
Parce que, bien sûr, on peut recréer +/- les mécanismes d'Access en Excel, en incluant la problématique des références vers d'autres tables, mais
- c'est réinventer la roue;
- se passer de toute façon de l'intégrité référentielle, +/- sauf usine à gaz protégée ou les feuilles sont verrouillées et tout se fait par userform ( et encore, il faudra super bien gérer les erreurs de code partout);
- utiliser un outil qui n'est pas du tout fait pour cela;
- se priver du langage sql pour les opérations CRUD (natif et transparent dans Access, et tellement abominable en Excel que c'en est pitié;
- pondre des centaines/milliers de lignes de code pour réaliser moins bien, plus lentement et de façon fragile ce qu'Access fait nativement sans code en quelques minutes;
- ...
- ...
- ...
Ah, ça c'est un tuyau. Merci.
Pour le reste, tu prêches un converti (bien qu'assez ignorant!)
Cordialement
Pierre
Pourtant j'ai enregistré mon fichier en 97-2013
Quel est ta version Windows?
Je crois savoir que la version MDB (Access 97-2003) utilisée lors d'une redescente de version avec Access 2007 ou ultérieur est en fait une version Access 2002-2003 non compatible avec Access 97, malgré l'extension MDB. Tout comme je pense qu'un Access 2007 ou ultérieur ne sait pas lire un fichier 97 sans l'upgrader d'abord...
Le lien suivant met ce problème en évidence, je pense: https://support.microsoft.com/fr-be/...f-your-applica
Access97, c'est vraiment trèèèès vieux, en termes de techno (Ce n'est pas une critique bien sûr, juste l'énoncé d'un fait.)
J'ais des fichier 97 qu'il faut Upgrader et des fichier crée sur 2016 365 et enregistré en 97-2003 qui tourne sur 97 sens problème.
bonjour,
En fait mon Access dit "A propos de" ver. 2000. Ce n'est pas pour le peu que je l'utilisais que j'allais casser ma tirelire. Mais j'ai plus travaillé sur Access depuis février 2018 que de 2000 à fin 2017. Maintenant la ver. 2016 est installée mais je ne l'ai pas encore ouverte. J'hésite car je suis moi aussi trèèèèès vieux:D et AC 2000 m'allait bien.
Voyons cette nouvelle interface.
Bien à vous
T_a_t
Bonjour,
j'ai un problème de relation :weird:
entre les Table : TblPersonne et TblNaissance et TblDeces
solution 1 :
Pièce jointe 365271
solution 2 :
Pièce jointe 365273
sachant que dans TblPersonne : IDNaissance et IDDeces sont identique à IDPersonne et peuvent être supprimés (dans solution 1)
que faire ?
@+JP
re,
si on suis les : 1 vers infini , la solution 2 semble la plus naturelle ... ;)
@+JP
Solution 1 car les tables Naissance et Décès sont en fait des extensions de la table des personnes en relation 1:1, en supprimant IDNaissance (clé primaire), en mettant IDPersonne comme clé primaire non autoimplémentée et en liant les IDPersonne. Ca créerait une relation 1:1 et ce serait plus logique qu'une relation 1:n.
On pourrait aussi placer les champs de ces deux tables dans la table des personnes, tant qu'à faire, sauf si on dépasse 255 champs.
On pourrait aussi créer un table Naissance_Deces puisque les champs sont identiques dans les deux tables, et ajouter alors un champ pour dire le type d'événement (naissance ou décès) qui est renseigné. Alors, dans ce cas, un IDNaissance_Deces serait justifié et on aurait alors une relation 1:n avec la table des personnes sur les champs IDPersonne.
Bonjour,
mjpmjp cite Lénine: "Que faire ?". Et moi aussi, un peu plus bas !Citation:
que faire ?
Mais d'abord mjpmjp: ta toile d'araignées de relations me surprend. Il se peut que je sois totalement dans l'erreur mais il me semble qu'il suffit que les relations portent sur des éléments qui évitent toute confusion entre deux enregistrements (ou entre deux compositeurs). De ce point de vue ID, Nom et Prenom suffisent. Les autres caractères (Naissance, Deces, Pays etc.) servent uniquement à la description de l'individu (pure information destinée à l'utilisateur).
D'autre part, comme je l'ai noté hier, chaque compositeur peut avoir recours à plusieurs "langages" ou techniques musicales (ou à aucun(e), du moins explicitement); par conséquent il faut traiter "langages" (dont je n'aurais pas dû faire une table, sinon comme pense-bête pour moi-même) comme une/des propriété(s) de chaque instance de la classe "musiciens", raison pour laquelle j'avais prévu de donner la forme d'une Collection VBA à cette propriété.
De mon point de vue, les relations (de type plusieurs à plusieurs) se limitent aux relations entre eleves et maitres par l'intermédiaire d'une table "liaison", soit 3 tables en tout et pour tout.
J'en viens à mon problème. Je m'y retrouve à peu près dans l'interface d'Access 2016, drôlement différente de ma trèèèèès vieille interface 2000 mais je bute toujours sur le même couac, le message genre "Impossible de créer ces relations avec intégrité relationnelle parce que la table "liaison" ne remplit pas les conditions voulues, c'est-à-dire que des enregistrements qu'elle contient ne figurent pas dans les tables primaires." Or j'ai vérifié à plusieurs reprises: ma table liaison contient un couple eleve_maitre formé d'enregistrements pris dans les 2 tables concernées (si je laisse la table "liaison" vide j'ai le message d'erreur "ne peut pas contenir une valeur Null").
Je ne comprends pas ce qui se passe (c'était déjà le cas il y a des semaines avec Access 2000 quand j'ai décidé de passer à Excel qui ne pose pas ce problème ). Mais maintenant que je peux compter sur votre aide experte je vais franchir l'obstacle. Et je vous en remercie d'avance.
Cordialement
Pierre
alias touche_a-tout
