Sql datum en tijd vergelijking van dubbele tabel

Oké, ik denk dat ik je heb. Wil je het volgende doen?

select <columns>
  from my_table
 where state_date <= <some date>
   and state_time <= <some time>

Het is vrij ongebruikelijk om om milliseconden te geven, maar als je dat doet, moet je systimestamp gebruiken .

Afgaande op het feit dat je datum en tijd hebt gesplitst, zijn dit karakters, dus ik moet de maskers opmaken . Als ze het bij het verkeerde eind hebben, zou de link u moeten helpen met wat u moet doen. Het is trouwens niet verstandig om een ​​date op deze manier te splitsen. U kunt een kolom maken met behulp van de timestamp gegevenstype in uw tabel, wat uw probleem uiterst eenvoudig zou maken.

Dus ik weet niet waarom je de 'Day' hebt gekozen formaat voor uw zoekopdracht, maar met die <some date> wordt to_char(sysdate, 'DAY') .

Uit je reactie hieronder <some date> zou zijn to_char(sysdate, 'DD-MON-YY')

<some time> zou zijn to_char(systimestamp,'HH24:MI:SS:FF3') , wat u de tijdstempel tot op de milliseconde zou geven, hoewel het gegevenstype tot in de microseconde kan gaan.

Het lijkt me een beetje vreemd, maar je vraag zou dan worden:

select <columns>
  from my_table
 where state_date <= to_char(sysdate, 'DD-MON-YY')
   and state_time <= to_char(systimestamp,'HH24:MI:SS:FF3')

Het zou normaler zijn, als u een datum opslaat als een string, om deze op te slaan in het formaat yyyymmdd dus je kunt tenminste garanderen dat het in orde is. Als je zoiets hebt gedaan, verander dan gewoon het formaatmasker. Als u dat niet hebt gedaan, zullen deze query's niet werken zoals bedoeld.

Persoonlijk, als je hebt om gegevens op deze manier op te slaan en uit te gaan van state_date wordt opgeslagen als, zeg, dd-mon-yy , d.w.z. inclusief jaar, maand EN dag en state_time is opgeslagen zoals hierboven aangegeven, dan zou ik zoiets als dit doen:

select <columns>
  from my_table
 where to_timestamp(state_date || state_time, 'DD-MON-YYHH24:MI:SS:FF3')
        <= systimestamp

Het maakt het veel duidelijker wat er aan de hand is en er is geen onduidelijkheid over wat < betekent in deze situatie dat een datum altijd lager zal zijn dan een toekomstige datum, wat niet noodzakelijk geldt voor strings.

Ik hoop dat dit logisch is.