Bonjour, j'ai un petit soucis avec une requete sur une table. J'utilise SQLite dans un programme C.
 
ma table comporte 3 champs : id StartTime EndTime.
StartTime et EndTime sont des dates/heures au format 2007-01-10T16:00:00Z
la table contient des valeurs sur une semaine, pour un endtime j'ai un start pour chaque id (sauf les bornes).
 
j'ai donc des entrées du type :  
 
1;2007-01-10T16:00:00Z;2007-01-10T16:30:00Z
1;2007-01-10T16:30:00Z;2007-01-10T16:32:00Z
1;2007-01-10T16:32:00Z;2007-01-10T16:41:00Z
..
et bien sur idem avec d'autres id.
 
 
la requête pour avoir les événements courrants ( au 2007-01-10T16:00:00Z par exemple) est simplement :  
 
SELECT id,StartTime,EndTime
FROM matable
WHERE StartTime >= '2007-01-10T16:00:00Z' AND EndTime < '2007-01-10T16:00:00Z'
 
je voudrais maintenant faire une requête sur les événements suivants ceux en cours.
il faut que je fasse une requête en prenant pour Start le End avec le même ID
 
je pensais utiliser
 
SELECT id,StartTime,EndTime
FROM matable
WHERE (id,StartTime) MATCH (SELECT id,EndTime
       FROM matable
       WHERE StartTime >= '2007-01-10T16:00:00Z' AND EndTime < '2007-01-10T16:00:00Z')
 
mais SQLite n'a pas l'air de supporter les doublons pour un match
 
 
utilisant SQLite dans un programme en C je peux toujours faire la requete NOW recupérer les resultats et faire autant de requetes que de resultat avec
SELECT id,StartTime,EndTime
FROM matable
WHERE id = id_recupere
 AND StartTime = EndTime_recupere
 
mais si SQLite peut me faire ça en 1 requete, cette solution serait plutot moche et moins performante.

Déjà, soit c'est une Date (donc pas de format) soir c'est un Varchar (et donc pas une date).
Faut choisir
 
Ceci dit je sais pas ce que tu va chercher avec MATCH (c'est quoi ce truc proprio encore ?) :
 

 
Ca devrait marcher non ?
 
-- correction de la requête (chelou qu'elle marchait avant )

PS : Et au lieu d'écrire la date courante comme un goret dans la requête, utilise la fonction de SQLLite qui permet de trouver la date courante. Genre "sysdate", "GetDate()", "Now()", etc.

merci beaucoup ça marche impeccable et en plus c'est très simple.  Mon SQL est (beaucoup) rouillé, ça date un peu la dernière fois que j'en ai utilisé et ce n'était pas très poussé.
 
re merci beaucoup !
 
ps : match n'est pas proprio  
ps2 : pour mon test ce sont des données passées donc c'est pour ça que j'ai mis la date en dure j'utiliserai effectivement quelque chose dans le genre si c'est supporté par SQLite.
ps3 : SQLite gère uniquement des types NULL INTEGER REAL TEXT BLOB. sans longeur fixe ou max pour les chaines de caracteres.

Tu peux caster un Date en REAL ou en INTEGER, selon si tu utilises le système Unix (INTEGER = nb millisecondes depuis 1/1/19** 00:00:00) ou Windows (ou OA pour OLE Automate) (REAL = partie entière = nb jours depuis 30/12/1999 / partie décimale = fraction de la journée [.5 = midi])
A défaut, utilise le format ISO-chais-plus-combien : YYYY-MM-DD h24:mi:ss (ou format compressé : YYYYMMDDh24miss) qui est triable, se stock aussi bien dans un text qu'un integer, et qui est facile à lire.
 

 
** : chais plus combien ? 1970 ? chais plus
 
MATCH, tu l'as vu avec quel SGBD ?
Je connais bien une instruction MATCH (non normalisée) mais qui ne s'utilise pas du tout pour faire ce que tu voulais faire. Ca sert habituellement à faire des recherche dans des index de texte intégral.

Pour la date je n'ai pas vraiment le choix du format  c'est une donnée que je me reçois qui arrive de cette façon ce qui ne me gene pas vu qu'on peut comparer avec les outils ad'hoc pour les chaines.
 
MATCH je l'ai vu en regardant http://sql.developpez.com/sqlaz/sousrequetes/ mais comme on peut le voir en bas de la page ce n'est quasiment pas supporté. le site ne précise pas si c'est un élement de la norme mais tel que c'est présenté je le suppose.
 
C'est bien de cette instruction dont je parle, comme de toute façon tout ou presque (dès que ce n'est pas un nombre) est du TEXTE dans SQLite donc ...
 

 
je n'avais pas fait un copié collé brutal mais réécrit      ce n'est pas exactement les noms des champs que j'utilise et que j'ai mis ici. Voila le pourquoi du comment.

pour le match, c'est donc pas le truc habituel (super, encore un homonyme, comme s'il n'y en avait pas assez...)
 
on dirait que c'est une tambouille de MySQL (ils ont pas mal de trucs dans ce genre). Certainement supporté par PostGre, et Oracle doit proposer un équivalent hors norme. A priori, le match donc tu parles pourrait faire l'objet d'une version de SQL récente (20xx). Vu que la plupart des SGBD ont encore du mal avec SQL92 (pourtant la première version de la norme) on va peut-être pas s'enflammer tout de suite hein ?
 
Sinon, tu trouveras régulièrement MATCH (sur la plupart des SGBD) mais dans un autre sens :
 
http://dev.mysql.com/doc/refman/5. [...] earch.html
 
Ca permet de faire des recherche "naturelles" dans une table. C'est utilisé de pair avec CONTAINS et FREETEXT généralement.

On devait parler de la meme chose :  le FullText Search   mais la syntaxe est juste différente.
 
La version présenté dans developpez.com est normallement la norme, (leur image sql2 qui le montre, si il respecte l'intro héhé)
ce qui correspond effectivement à la norme ( http://www.contrib.andrew.cmu.edu/ [...] ql1992.txt  point 8.10 )  
et SQLite qui utilise une syntaxe très proche http://www.sqlite.org/cvstrac/wiki?p=FullTextIndex mais qui est de tout façon très limité.
 
comme tu le dis c'est MySQL qui a implémenté ça à leur sauce.

le truc SQL2 n'a rien à voir avec FullText Search... Il s'agit de traîter des lignes en tant que tuples. MATCH sert ici à tester l'égalité entre deux tuples (c'est dire deux lignes identiques).
 
Avec FullText Search, MATCH (qui travaille avec AGAINST) sert à trouver l'orrurence d'une série de mots clés dans un champ, et retourner une valeur de pertinance. Rien à voir
 
Dans tous les cas, oublie le MATCH de ton exemple, très peu de SGBD le supportent

OOps au passage dans ce que j'ai posté j'ai mis un  Start >= NOW et NOW > End     c'est bien sur Start <= NOW and NOW < END
dans ce que je testais c'était dans le bon ordre ^^