From: genew@ocis.net   
      
   On Wed, 01 Aug 2012 20:59:06 +0200, Erland Sommarskog   
    wrote:   
      
   >Gene Wirchenko (genew@ocis.net) writes:   
   >>      It is not multiple errors.  It is multiple rows of error data   
   >> being returned.  Preliminarily, it is an error message row followed by   
   >> zero or more rows of inculpated column names.  e.g.   
   >>           OrderBy  ErrorResponse   
   >>              0     Foo must be less than bar.   
   >>              1     foo   
   >>              2     bar   
   >> 0 is the error message to be emitted.  1 and 2 are the involved   
   >> columns from which the front-end will select the first one in the form   
   >> tab sequence to set the focus to.   
   >   
   >There are of course error checks that belongs in the database, because   
   >they work with the data. This does not the least apply to update procedures.   
      
        Huh?  Of course it involves updates.  I do not want bad data   
   getting into the database.  That is the point of the error checks.   
      
        Did you misstate, or am I missing some context here?   
      
   >However, I would recommend that you don't overdo it. T-SQL is not a very   
   >good language from a general programming perspective. Earlier this day   
   >I was battling how to formulate an error message that for a while read   
   >like:   
   >   
   >   Column(s) [a] exists only in the left table, but they are not at the end   
   >   
   >While the message can apply to multiple columns, I expect that most commonly   
   >there will be only one, so the bad grammar will hurts the eye. Had I written   
   >this code in Perl I might have crafted a message that was correct both   
   >for singular and plural, but in T-SQL the code for that would be just too   
   >verbose, and I eventually I found a way to convey the message that did   
   >not depend on verb inflection.   
      
        I have already written some proof-of-concept code that does   
   return what I need.  To do so, I created a constraints table that has   
   the names of the columns associated with each constraint.  That is   
   where I get the columnnames that are returned to the browser.  I think   
   it will scale up.   
      
   >I think I've written something like you have in mind about once in my   
   >career. And that was in SQL 2000 with no TRY-CATCH. With TRY-CATCH it   
   >becomes even more difficult to produce multiple error message. Unless   
   >you return them as result sets, but then you need a clear protocol so   
   >that your client knows what result set gets back.   
      
        My protocol that I have already described is simple.  I think it   
   will work.   
      
   >Something I've used a little more often is when I have had a table with   
   >rows that needs to be processed, and each row is processed independently, or   
   >at least there are groups of rows that are independent of each other.   
   >In such cases, I put a status column and a message column in the table   
   >where I write error status and message.   
      
        Do you mean that your input table gets modified with the result?   
   Something like:   
             SomeKey     }   
             Data1       } Process   
             Data2       } this.   
             Data3       }   
             ProcessingStatus           } What happened   
             ProcessingErrorMessage     } goes here.   
      
   Sincerely,   
      
   Gene Wirchenko   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)