97d0c5e2   
   From: sorrytoomuchspamalready@xs4all.nl   
      
   RRR wrote:   
   >   
   > >   
   > > Are you sure you correctly stated the original problem?  I also wonder if   
   > > there was a reason the original values were stored in a table.   
   >   
   > I, too, was concerned about that.  If this were to be used as a means   
   > of transforming any score to the correct grade, then the CASE approach   
   > shown would have to specify all possible expected score values.   If   
   > that is the case, then the CASE statement should be more generalized   
   > so as to map a range of scores to a letter grade.   
      
   In this case a CASE expression would not be my first choice. My first   
   choice would be to create a table (in case one doesn't already exist)   
   with a mapping between the different grade types (or range of grade   
   types).   
      
   In its simplest form:   
      
   CREATE TABLE grades   
   (grade_number tinyint NOT NULL PRIMARY KEY   
   ,grade_letter char(1) NOT NULL   
   )   
   INSERT INTO grades VALUES (50,'F')   
   INSERT INTO grades VALUES (60,'D')   
   INSERT INTO grades VALUES (70,'C')   
   INSERT INTO grades VALUES (80,'B')   
   INSERT INTO grades VALUES (90,'A')   
   INSERT INTO grades VALUES (100,'A')   
      
   SELECT ..., grades.grade_letter   
   FROM my_table   
   JOIN grades   
     ON grades.grade_number = my_table.grade   
      
   I think that for this type of applications, the solution with a CASE   
   expression should be reserved for ad-hoc selections, which I don't think   
   this is.   
      
   --   
   Gert-Jan   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)