Interbase: Problème de case dans un SELECT [Résolu]

[mameziane]

Bonsoir à tous;
Je développe une application en Delphi avec une base de données Interbase.
Je rencontre depuis des heures un problème avec la requête suivante:
(là je simplifi la reqûete)

Code :

1
2
3
4
5
6
7
8
9
10
11
12
 
 
SELECT 
   matable.IDNUM, 
   matable.AUTREDATE , 
   matable.MADATE, 
   case when matable.MADATE >= '11/08/2007' 
       then 0 
       else 1 
       end  AS MONINDIC
FROM matable 
WHERE matable.AUTREDATE > '11/01/2007'

sachant que le format date de interbase est mm/dd/yyyy

J'ai essayé le IF , IIF mais ça ne fonctionne pas !

Merci d'essayer de m'aider

[qi130]

Quelle version d'Interbase ?

Quelle erreur se produit ?

[mameziane]

Envoyé par qi130

Quelle version d'Interbase ?

Quelle erreur se produit ?

Tout d'abord merci de vous intéresser à ma question

voici l'erreur:

ISC ERROR CODE:335544569

ISC ERROR MESSAGE:
Dynamic SQL Error
SQL error code = -104
Token unknown - line 6, char 7
when
STATEMENT:
TIBOInternalDataset: "<TApplication>.frm_DBS_SQL_Entry.qry.IBOqrqry."

J'utilise Interbase 6 que voici l'écran de son About..

avec Delphi 7 muni des composant de la JVCL

[Barbibulle]

Bonjour,

Interbase 6 ne gère pas de "Case".
Cette notion a été introduite dans firebird 1.5 (quipeux remplacer Interbase 6 presque sans aucun probleme de conversion).

Et je pense que le "case" existe sous interbase > à la version 7.x (A faire confirmer).

Si vous voulez le faire sous Ib6 il vous faudra passer par une procédure stoquée ou bien un select Union poura faire l'affaire.

Cordialement

[mameziane]

Bonjour,
Je ne pense pas que je pourrais changer vers firebird tout de suite mais la solution de SELECT UNION sera la mieu adaptée
comment pourrais-je ajouter cette condition dans un SELECT

[Barbibulle]

Preferez le format date AAAA/MM/JJ qui est moins ambigu.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
SELECT 
   m.IDNUM, 
   m.AUTREDATE , 
   m.MADATE, 0 AS MONINDIC
FROM matable m
WHERE m.AUTREDATE > '2007/11/01'
   AND m.MADATE >= '2007/11/08' 
UNION
SELECT 
   m.IDNUM, 
   m.AUTREDATE , 
   m.MADATE, 1 AS MONINDIC
FROM matable m
WHERE m.AUTREDATE > '2007/11/01'
   AND m.MADATE < '2008/11/08' ;

[qi130]

Envoyé par Barbibulle

Et je pense que le "case" existe sous interbase > à la version 7.x

J'ai effectivement trouvé des infos dans ce sens sur , d'où ma demande quant à la version.

[mameziane]

Merci le PROs pour vos réponses, en fait vu ma requete qui est trés complexe, je vais rediriger le SELECT vers une table temporaire puis en parcourant cette table je vais modifier mes indicateurs qui sont au nombre de 6 avec des update.
Mais maintenant je rencontre un autre type de problème je possède deux champs de type timestamp que je ne peux pas comparer avec une date !
Ma question est : comment extraire une date d'un champ TIMESTAMP dans un SELECT ?

[Cl@udius]

Envoyé par mameziane

comment extraire une date d'un champ TIMESTAMP dans un SELECT ?

avec un CAST:

Code :

1
2
 
  SELECT CAST(MonChampTimeStamp AS DATE), ...

@+ Claudius

[mameziane]

Meci Cl@udius ca fonctionne pour le Timestamp.
Mais là encore je me plante sur :

Code :

SELECT * FROM Matable INTO TableTemp

qui apparemment ne fonctionne pas avec Interbase 6 !
Y-a-t-il d'autre moyen pour rediriger le résultat du select vers une autre table ?

[Cl@udius]

Re,

As-tu essayé dans l'autre sens:

Code :

1
2
3
 
  INSERT INTO TableTemp
  FROM (SELECT ...);

?

@+ Claudius

[mameziane]

En fait j'ai pas pensé, je vais essayé d'adapter cette requête avec la tâche à réaliser et je vous en dirais de mes nouvelle
Encore merci

[Barbibulle]

A votre place je ferai une procédure stoquée. Celà évitera de dédoubler des données et d'allourdir le traitement (dans votre cas, un select/insert, puis des Updates pour enfin faire un select du résultat).

Qeulque chose du genre :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
CREATE procedure MaProcedure(MaDateParam date, MaDateParam2 date)
returns (IDNUM integer,
    Autredate date,
    Madate date,
    MONINDIC smallint)
 
AS
begin
  FOR SELECT matable.IDNUM, matable.AUTREDATE, matable.MADATE
  FROM matable 
  WHERE matable.AUTREDATE > :MaDateParam
  INTO :IDNUM, :AUTREDATE, :MADATE
  do
  begin
     IF (MADATE >= MaDateParam2) then
       MONINDIC = 0;
     else
       MONINDIC = 1;
     end
    suspend;
  end
end

Puis pour l'utiliser il vous suffit de faire un select :

Code :

SELECT Autredate, Madate, MONINDIC FROM MaProcedure( '2007/11/1', '2007/11/8')

[SergioMaster]

Attention toutefois au SQLDialect

si c'est le 1 bien indiqué la date et l'heure 00:00:00
(je viens de me faire avoir , donc je parle d'expérience)
Date est un TimeStamp en dialect 1 alors qu'en dialect 3 c'est bien juste la date

je ne sais plus ou j'ai trouvé sur le net la difference entre les dialects 1,2,3
mais c'est édifiant

[Barbibulle]

Sauf qu'il n'y a aucune raison d'utiliser la dialect 1 ou 2 avec IB6.

Pour rappel le Dialect 1 etait celui utilisé par les versions antérieures à la V6. Le dialect 2 a été crée dans l'unique but de faciliter la migration vers le dialect 3 qui est celui qu'il faut utiliser dans les versions >= 6.

[mameziane]

Merci les Pros pour vos précieux conseils.
En fait et après plusieurs test, vus qu'en réalité ma requête conserne 6 champs de date dont deux son en timestamp, j'ai décidé d'ajouter des champs flag type ARR varchar(1) pour controler la date d'arrivée, DEX varchar(1) pour la date début d'exécution, etc... chaque date aura un indicateur qui sera modifié en même temps que la date correspondante et qui aura 1 si la date est dans la plage désiré sinon 0 par 6 requetes UPDATE et puis lors du SELECT que se soit à l'affichage dans une grille ou à l'impression chaque indicateur servira comme critère de selection.
Désolé de vous décevoir en utilisant cette solution (de cuisine) mais vu que je suis encore débutant (depuis 7 ans déjà) je n'ai pas pu faire mieux.
Encore merci à tous

[Barbibulle]

C'est en effet dommage de n'avoir pas créer une petite procédure stockée qui aurait été une solution plus élégante et plus pérène.

Sans compté que celà vous aurait pris moins de temps à développer.

Se plus si un jour une des règles changent vous allez devoir mettre à jour toute votre table pour que les flags reflètent bien la nouvelle règle.

Et combien de flag allez vous devoir ajouter au fil de votre développement ?