Discussion :

[okparanoid]

Bonjour !

J'ai une base de donnee de suivi d'activites avec des tables qui devront etre mises a jour par plusieurs utilisateurs (une cinquantaine). Vu que je dois faire ca en Access, je me reserve la possibilite de soit avoir un fichier par utilisateur soit par equipe de 8 et de tout regrouper mensuellement avec une fonction d'agregation pour sauvegarder les donnees et generer les stats totales, l'essentiel etant que chaque utilisateur ait les donnees qui lui sont propres a sa disposition.

Du coup dans mes tables aggregees je vais avoir le suivi des activites de l'ensemble des utilisateurs. Se pose alors la question de savoir comment choisir la cle primaire de chaque activite rajoutee dans la base de l'utilisateur pour qu'a l'aggregation je n'ai pas de probleme de doublons d'identifiants. Est-ce que vous pensez que choisir en identifiant les 6 lettres de l'identifiant de l'utilisateur + date heure minutes de l'enregistrement est un bon choix ou pour une cle indexee cela va faire trop long ?

Merci pour vos conseils, je n'ai pas trop l'habitude de gerer des bases de donnees...

[agasse51]

Bonjour !

J'ai une base de donnee de suivi d'activites avec des tables qui devront etre mises a jour par plusieurs utilisateurs (une cinquantaine). Vu que je dois faire ca en Access, je me reserve la possibilite de soit avoir un fichier par utilisateur soit par equipe de 8 et de tout regrouper mensuellement avec une fonction d'agregation pour sauvegarder les donnees et generer les stats totales, l'essentiel etant que chaque utilisateur ait les donnees qui lui sont propres a sa disposition.

Du coup dans mes tables aggregees je vais avoir le suivi des activites de l'ensemble des utilisateurs. Se pose alors la question de savoir comment choisir la cle primaire de chaque activite rajoutee dans la base de l'utilisateur pour qu'a l'aggregation je n'ai pas de probleme de doublons d'identifiants. Est-ce que vous pensez que choisir en identifiant les 6 lettres de l'identifiant de l'utilisateur + date heure minutes de l'enregistrement est un bon choix ou pour une cle indexee cela va faire trop long ?

Merci pour vos conseils, je n'ai pas trop l'habitude de gerer des bases de donnees...

Bonjour,
Les 2 solutions que tu proposes ne me semblent pas correctes.
A mon avis, il doit y avoir 1 seule table pour la saisie
Il suffit de définir un champ "user_name" de type caractère.
Lors du lancement de l'application, on récupère le code de l'utilisateur.
Pour la gestion des données tu utilises un query :
"Select * from matable where user_name = :USER"
Lors de la création d'un nouveau record, la valeur de user_name mis à jour par ton applic.

[okparanoid]

Merci pour ta réponse mais je crains qu'une seule table pour la saisie ne soit guère réalisable a 50 utilisateurs. D'ou l'idée de restreindre a une base par utilisateurs ou par équipe, et d'aggreger chaque fin de mois pour pouvoir generer les stats.

L'idéal serait d'avoir un système C/S mais pour l'instant je dois rester sous Access. Est-ce que la solution d'avoir plusieurs bases vous parait réalisable et dans ce cas je ne sais pas comment gérer idéalement la generation des identifiants de cle primaire sans risquer d'avoir des doublons sur la base agregee...

[agasse51]

Merci pour ta réponse mais je crains qu'une seule table pour la saisie ne soit guère réalisable a 50 utilisateurs. D'ou l'idée de restreindre a une base par utilisateurs ou par équipe, et d'aggreger chaque fin de mois pour pouvoir generer les stats.

L'idéal serait d'avoir un système C/S mais pour l'instant je dois rester sous Access. Est-ce que la solution d'avoir plusieurs bases vous parait réalisable et dans ce cas je ne sais pas comment gérer idéalement la generation des identifiants de cle primaire sans risquer d'avoir des doublons sur la base agregee...

D'après ce que j'ai trouvé sur internet, il y avait une limitation de 10 users pour les version 16 bits d'acces
http://support.microsoft.com/default.aspx/kb/154869

La solution de la clé unique que tu proposes ne marche pas si tu ne tiens pas compte de la seconde. A par ca, cela ne pose pas de problème

Je te propose la solution suivante qui est plus simple
Dans tes tables de saisie tu a 2 champs pour la clé unique
noTable = octet
id = soit un autoincrément soit un entier dont tu gères le no
Chaque table de saisie à son propre no de table qui sera toujours le même

Tu n'as ainsi aucun problème de consolidation