Oracle OCI: requête avec champ Date

Question

client compilé avec OCI: 10.2.0.4.0
serveur: Oracle9i Édition Enterprise version 9.2.0.4.0

La requête est problématique:

SELECT CODIGO FROM LOG WHERE TEL = :telnumber AND DATE_PROC = '05-JUL-08' 

Table Description:

SQL>describe LOG; 

TEL NOT NULL VARCHAR2(15) 
CODIGO NOT NULL VARCHAR2(20) 
DATE_PROC NOT NULL DATE 

aussi simple que cela peut paraître, lorsqu'il est exécuté directement sur le serveur avec SQLPlus, il renvoie un résultat, mais lorsqu'il est exécuté à partir de l'application qui utilise OCI, cette requête renvoie OCI_NO_DATAtoujours. Au début, la valeur date était aussi un espace réservé, mais j'ai découvert que même donner un littéral comme '05-JUL-08' ne fonctionnait pas. J'ai essayé ce qui suit:

• J'ai essayé les bases: l'interrogation du DB du client fonctionne. Il est celui qui me donne du mal

• Ce qui suit fonctionne:

  SELECT CODIGO FROM LOG WHERE TEL = :telnumber 
  

• exécution ALTER SESSION SET NLS_DATE_FORMAT="DD-MM-YYYY"; avant que la requête dans le serveur et le client. Même résultat: le serveur renvoie les données, client OCI_NO_DATA

• Essayé de changer le format DATE_PROC, en combinant ceci avec l'utilisation de TO_DATE(). Même résultat
• Recherché, recherché, recherché. Pas de réponse

Je suis un peu désespérée pour trouver une réponse, j'apprécierais toute aide et je pourrais fournir autant de détails que nécessaire. Merci.

--- Plus d'infos ---

update log set DATE_PROC = TO_DATE('20080705162918', 'YYYYMMDDHH24MISS') where CODIGO='BancoOne'; 

J'ai essayé différentes combinaisons en utilisant trunc() et "modifier session de jeu NLS_DATE_FORMAT" ... et voici ce que je reçois:

SELECT CODIGO FROM LOG WHERE TEL = 11223344 AND DATE_PROC = TO_DATE('20080705162918', 'YYYYMMDDHH24MISS'); 

dans le serveur: retour: "BancoOne" (bonne valeur)
Dans l'application OCI: Retours OCI_NO_DATA

SELECT CODIGO FROM LOG WHERE TEL = 11223344 AND trunc(DATE_PROC) = TO_DATE('20080705', 'YYYYMMDD'); 

dans le serveur: retour: « BancoOne »
Dans l'application OCI: Revient « BancoOne »

Ainsi, le point est, pourquoi l'application OCI variant les résultats si les deux accèdent au même serveur DB? En outre, pour clarifier le but de l'application OCI: il a une requête à configurer par l'utilisateur. L'idée est que l'utilisateur adaptera la requête pour qu'elle corresponde au champ Date présent dans la base de données de destination, c'est pourquoi je ne devrais pas inclure les instructions "alter set set nls_date_format" dans mon code, car je ne connaîtrais pas le format de date. De cette façon, je veux offrir de la flexibilité à l'utilisateur, et ne pas compter sur des formats de date spécifiques. Est-ce que ça a du sens? Aucune suggestion?

Answer 1

votre colonne DATE_PROC est une date, vous devriez toujours comparer à une date et jamais compter sur la conversion des données implicites.

Essayez ceci:

SELECT CODIGO FROM LOG WHERE TEL = :telnumber AND DATE_PROC = DATE '2008-07-05' 

ou ceci:

SELECT CODIGO 
    FROM LOG 
WHERE TEL = :telnumber 
    AND DATE_PROC = to_date('05-JUL-08', 'DD-MON-RR') 

Si vous pouvez, évitez d'utiliser un format de date dans votre code qui utilise des lettres pendant des mois (parce que le code sera échec lorsque vous changez la langue par défaut) et seulement deux caractères pour les années (ambiguïté du siècle). J'aime utiliser 'YYYY/MM/RR' car ce format sera trié en tant que date d'origine.

Answer 2

Comment les notices ont-elles été insérées?

Les champs de date stockent des informations sur l'heure. Ainsi, lors de l'insertion d'enregistrements à l'aide de sysdate, le champ de date contient différentes «valeurs» pour les enregistrements de ce jour. Lorsque vous exécutez date_proc = '05 -JUL-08 ', vous dites où date_proc correspond exactement au 5 juillet 2008 à 12:01:00. Si vous avez inséré l'enregistrement à 12:01 avec sysdate, il ne sera pas retourné. Avez-vous essayé d'utiliser un entre ou trunc?

Voici un exemple:

drop table test_date; 
create table test_date (id number, ud date); 

insert into test_date values (1, '15-jan-10'); 
insert into test_date values (2, '15-jan-10'); 
insert into test_date values (3, '15-jan-10'); 
insert into test_date values (6, sysdate); -- sysdate as of writing is 15-JAN-2010 08:01:55 
insert into test_date values (7, sysdate); -- sysdate as of writing is 15-JAN-2010 08:01:55 
insert into test_date values (8, '16-jan-10'); 
commit; 

select id, ud, to_char(ud, 'dd-MON-yyyy HH:MM:SS') from test_date where ud = '15-jan-10'; 
---------------------- ------------------------- -------------------- 
1      15-JAN-10     15-JAN-2010 12:01:00               
2      15-JAN-10     15-JAN-2010 12:01:00               
3      15-JAN-10     15-JAN-2010 12:01:00  

select id, ud, to_char(ud, 'dd-MON-yyyy HH:MM:SS') from test_date where trunc(ud) = '15-jan-2010'; 
---------------------- ------------------------- -------------------- 
1      15-JAN-10     15-JAN-2010 12:01:00               
2      15-JAN-10     15-JAN-2010 12:01:00               
3      15-JAN-10     15-JAN-2010 12:01:00               
6      15-JAN-10     15-JAN-2010 08:01:55               
7      15-JAN-10     15-JAN-2010 08:01:55 

Answer 3

Je dirais que vous posez la mauvaise question.

Oracle repose sur le partage de SQL pour les performances et lorsque vous collez une chaîne, comme '20080705', le SQL ne peut pas être partagé. Détails here. Par conséquent, la valeur de données doit être un espace réservé et doit être du type de données correct (DATE). L'exemple here devrait aider à faire cela.

Cela dit, si cela fonctionne

SELECT CODIGO FROM LOG 
WHERE TEL = 11223344 AND 
trunc(DATE_PROC) = TO_DATE('20080705', 'YYYYMMDD'); 

mais cela ne

SELECT CODIGO FROM LOG 
WHERE TEL = 11223344 
AND DATE_PROC = TO_DATE('20080705162918', 'YYYYMMDDHH24MISS'); 

Je tenterai

SELECT TO_CHAR(DATE_PROC,'DD-MM-YYYY HH24:MI:SS') FROM LOG 
WHERE TEL = 11223344 AND 
trunc(DATE_PROC) = TO_DATE('20080705', 'YYYYMMDD'); 

Answer 4

Nous avons juste eu cette erreur (OCI_NO_DATA) Inscrivez-vous causé par quelqu'un qui change l'heure du jour sur son pc. Quand ils ont remis la date/heure au bon moment, l'application a commencé à fonctionner correctement.