hello,

J'ai une DB avec des entrée de sous forme de
Je voudrais faire un query sur base d'une date, mais qui me rendrait les résultats qui ont heure IN après 6.00 et heure OUT avant le LENDEMAIN à 6.00.
Le but est de faire la liste des pointages de prestation pour un jour J, sachant que la nuit (22h->6h) fait partie du jour où ça commence et pas où ça fini.
Ca doit être possible, mais je ne sais pas comment faire.

dans mes mots, ca ressemblerai à



Je ne sais vraiment pas comment tourner l'histoire.

Merci

tourner cad, tu as quoi comme format concret dans ta DB?
et ton query actuel te donne quoi comme résultat/erreur?

Quel est le format utilisé pour stocker l'heure/date ?

Bon, deja, conceptuellement, y a une couille dans ton modele.
"OUT" devrait avoir une contrainte pour verifier qu'il est toujours apres le "IN" correspondant.
Or, avec le "date", tu te retrouves a avoir des incoherence du type "5h est apres 6h".
Il serait nettement plus facile de mettre un timestamp pour "IN" et "OUT" et laisser tomber le champs "date".
Ensuite, tu n'aurais qu'a faire une simple recherche ou "IN" serait sup au jour+6h demande et "OUT" serait inferieur a jour+1j+6h.

pour l'heure et la date, pour le moment, je crois que c'est une string.
La DB d'origine est un fichier XLS.
En fait, ce qui m'ennuie, c'est les parenthèses. Je ne sais pas si je peux les utiliser ou pas.
J'ai pas essayer le query tel quel, j'étais tellement sur que ca ne fonctionnerait pas

Attends, j'ai pas tout suivi.
Si j'ai une prestation de 23h qui commence à 6.30, elle va jusque 5.30 le lendemain, et elle est valide.
Je suis SUR que OUT est après IN. Toujours. Par contre, je ne peux pas laisser tomber la date, puisque le fichier contient des infos sur plusieurs jours et que je dois sortir un rapport quotidien.

Si tu codes tes timestamps sous le format AAAAMMJJHHMM, ça devrait être plus facile.

Par exemple :



Non ?

si tu n'as pas de contrainte sur "jour-heure" tu ne peux pas etre sur. Jamais. C'est pour ca que je dis qu'il faut au minimum mettre des timestamp.

That's my point.

C'est bien ce que je pensais.

oui, sauf que au départ, dans mon fichier, j'ai la date sous forme de "04/09/2007" et l'heure sous forme de "6.00" qui sont des strings.

Je fais comment alors?

PS : je ne sais pas modifier le fichier de départ, je le reçois tel quel et le but est de ne pas devoir commencer par chipoter dans le fichier...

euh, oui, mais tu recois un fichier ou une db? parce que si c'est un fichier, rien ne t'empeche de remplir la db comme bon te semble, hein

Germaine: d'autant plus que si tu sais que les prestations ne durent jamais plus de 24 heures, le probleme est encore plus con, car on pourrait meme se contenter de filtrer sur "date", donc je suppose que c'est plus subtile que ca en a l'air.

gizmo> +10

Il faut un champ qui réunit l'info de date et d'heure, facile à comparer, à vérifier, à afficher de façon splittée...

JC> Si c'est toi qui crée la db à partir du fichier excel, et que tu es maître du shéma de la db, refais ça en mieux

Pour récapituler:
Je reçois un fichier XLS.
Je l'attaque comme une DB pour pouvoir faire des requêtes plus complexes qu'un VLOOKUP.
Les prestations ne dure jamais plus de 24h, mais une prestation entre 2.00 et 3.45, par exemple est à compter sur la veille, puisque la pause de la nuit est comptabilisée dans la journée qui précède et pas celle qui suit. une "journée" va donc de aujourd'hui 6.00 à demain 6.00.

Je ne sais pas si c'est plus clair...

En général, les db ont un type spécifique datetime, non ? ...

Tu fais des query SQL sur un XLS sans passer par une db ?

Oui, mais j'ai toujours trouvé qu'avoir ce format particulier associé à une classe avec méthode pour les conversions, c'est plus mieux bien



Sous windows, il y a moyen de définir une source ODBC pointant sur un fichier XLS pour peu que les données des tables aient été définies via un NAME/RANGE.

Oué, puis si tu veux gérer des fuseaux horaires, ou les heures d'été, tu réinventes la roue...

Et perdre du coup toutes les methodes de convenance efficaces du DBMS? Je suis loin d'etre convaincu par cette approche.