IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Access Discussion :

Rapidité d'execution :RechDom sur Table ou Requete???


Sujet :

Access

  1. #1
    Membre actif Avatar de samlepiratepaddy
    Profil pro
    Inscrit en
    Juillet 2005
    Messages
    320
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2005
    Messages : 320
    Points : 217
    Points
    217
    Par défaut Rapidité d'execution :RechDom sur Table ou Requete???
    Slt,
    Une question de rapidité d'execution .
    Je dois faire un formulaire qui va comporter une centaine de champ indépendant (Style Planning de la semaine)
    Chaque champ correspond a un POSSIBLE rdv en fonction d'une heure et d'un jour !
    Le formulaire aura comme "visuel" les 7 jours suivants a aujourd'hui !
    Donc pour que dans la 1er colonne il n'y ai que les rdv de "demain", et ainsi de suite, je vais passer, je pense par RechDom dans la source du champs ..
    Un truc du genre
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    =RechDom([NomPrenom];"R_PlaningRdvCommerciaux";"[DateRendezVous]='(Date()+1)'and [HeureRendezVous]='08:00:00' ")
    (qui ne fonctionne pas d'ailleurs !!! )
    A voir le problème du format de la date ?? (surement US sur la SQL !)
    Ma question est :
    1/ Est-ce que ma façon de procédé vous semble cohérente?
    2/ Si oui, dois-je passer par une requete qui filtre les rdv avec (>Date()) et ensuite faire ma RechDom dessus OU passer directement par la Table RDV et mettre mon critère dans RechDom???
    Sachant que ce formulaire sera filtré a l'ouverture en fonction du commercial, et qu'il va y avoir une centaine de champ a "testé" est-ce que l'ouverture ne sera pas trop longue ???
    J'espère avoir bien expliquer mon problème...
    Merci de vos réponses.
    La connaissance ne vaut que si elle est partagée par tous et pour tous!
    Access et moi c'est mais en fait on s' bien !
    Ps: Je comprend très vite quand on m'explique longtemps !!

  2. #2
    Expert éminent
    Avatar de cafeine
    Inscrit en
    Juin 2002
    Messages
    3 904
    Détails du profil
    Informations forums :
    Inscription : Juin 2002
    Messages : 3 904
    Points : 6 781
    Points
    6 781
    Par défaut Re: Rapidité d'execution :RechDom sur Table ou Requete???
    Citation Envoyé par samlepiratepaddy
    1/ Est-ce que ma façon de procédé vous semble cohérente?
    2/ Si oui, dois-je passer par une requete qui filtre les rdv avec (>Date()) et ensuite faire ma RechDom dessus OU passer directement par la Table RDV et mettre mon critère dans RechDom???
    Sachant que ce formulaire sera filtré a l'ouverture en fonction du commercial, et qu'il va y avoir une centaine de champ a "testé" est-ce que l'ouverture ne sera pas trop longue ???
    J'espère avoir bien expliquer mon problème...
    Merci de vos réponses.
    1/ Non
    2/ Oui l'ouverture serait mortellement longue

    Soit tu trouves un composant OCX ou autre d'agenda.

    Soit tu le fais "maison"
    Si j'imagine ton appli avec une case pour un créneau horaire ...

    Base ton form sur une requête qui contient les données des 7 jours à venir, tu n'auras ainsi qu'un seul query à faire
    Je pense qu'au contraire tu devrais rendre tes contrôles dépendants.
    L'action double clic sur un des contrôles provoquerait l'ouverture d'un form de saisie de tâche ou de rendez-vous.
    Ne mettez pas "Problème" dans vos titres, par définition derrière toute question se cache un problème
    12 tutoriels Access



  3. #3
    Membre actif Avatar de samlepiratepaddy
    Profil pro
    Inscrit en
    Juillet 2005
    Messages
    320
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2005
    Messages : 320
    Points : 217
    Points
    217
    Par défaut
    Slt Cafeine
    L'action double clic sur un des contrôles provoquerait l'ouverture d'un form de saisie de tâche ou de rendez-vous.
    C'est exactement ce que je veux faire, et en fait en passant par une "liste" de champ (heure) par colonne (jour) indépendant, je pensais pouvoir "griser" les champs qui suivent celui du Rdv noter pour palier au problème de temps passé a ce rdv et interdire ou pas ainsi de remettre un autre rdv pendant ce temps d'execution du rdv !
    Parce qu'il y a aussi certain "type" de rdv qui peuvent etre doublés sur un horaire mais pas d'autres ...
    Bon je continu a chercher les possibilités en tenant compte de ce que tu m'a dis....
    Merci
    Mais j'suis preneur sur d'autres idées..
    La connaissance ne vaut que si elle est partagée par tous et pour tous!
    Access et moi c'est mais en fait on s' bien !
    Ps: Je comprend très vite quand on m'explique longtemps !!

  4. #4
    Expert éminent
    Avatar de cafeine
    Inscrit en
    Juin 2002
    Messages
    3 904
    Détails du profil
    Informations forums :
    Inscription : Juin 2002
    Messages : 3 904
    Points : 6 781
    Points
    6 781
    Par défaut
    Je maintiens que si tu rends tes controles indépendants, le rafraichissement sera long, long, long.
    Ne mettez pas "Problème" dans vos titres, par définition derrière toute question se cache un problème
    12 tutoriels Access



  5. #5
    Membre actif Avatar de samlepiratepaddy
    Profil pro
    Inscrit en
    Juillet 2005
    Messages
    320
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2005
    Messages : 320
    Points : 217
    Points
    217
    Par défaut
    Re,
    Ok, mon cher !
    J'ai chercher une autre soluce et j'ai opté pour celle du formulaire tableau dynamique !
    Au moins la présentation du planing est rapide et clair, mais cela ne règle pas mon problème d'interdire ou pas l'ajout d'un nouveau rdv sur le même horaire en fonction d'un type de rdv et du temps de traitement !
    1/ trois "type" de Rdv BRUT,VEILLE,NET
    2/ un "NET" ou "VEILLE" doit "bloquer" les 2 heures suivantes et donc interdire tous nouveaux rdv entre l'heure de ce rdv et + 2 heures !
    3/ le "BRUT" n'est qu'un futur "NET" mais auquel il y a encore une action a faire dessus ! d'ou la possibilité de "doublé" sur l'horaire mais pas "Triplé" !!
    4/ et le "VEILLE" est un rdv dont tous les "critères" sont réunis dès sa création !

    En résumé, quand sur une journée j'ai un rdv "net" ou "veille" (ex:à 10H00) il faut que je trouve le moyen d'interdire tous rdv jusqu'a 12H00
    Et si ce rdv est "brut" donner la possibilité de mettre un autre rdv a la même heure ! mais pas d'autres !!!

    Et là je vois pas comment faire???
    La connaissance ne vaut que si elle est partagée par tous et pour tous!
    Access et moi c'est mais en fait on s' bien !
    Ps: Je comprend très vite quand on m'explique longtemps !!

Discussions similaires

  1. Requete sur table récursive pour construire arbre
    Par dacid dans le forum Requêtes et SQL.
    Réponses: 3
    Dernier message: 13/06/2006, 17h17
  2. [MySQL] requete sur table jointe
    Par winnie82 dans le forum PHP & Base de données
    Réponses: 3
    Dernier message: 21/03/2006, 16h27
  3. Requete sur table avec Tableau
    Par Sichagadel dans le forum Langage SQL
    Réponses: 3
    Dernier message: 08/11/2005, 14h05
  4. TABLE pointant sur elle-même, requete de selection recursive
    Par Mike@Nestor dans le forum Langage SQL
    Réponses: 1
    Dernier message: 27/07/2005, 14h50
  5. Requete SQL sur table dbase et date du jour
    Par Jean-François PETIT dans le forum Bases de données
    Réponses: 5
    Dernier message: 29/03/2005, 09h31

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo