From: genew@ocis.net   
      
   On Tue, 31 Jul 2012 21:45:49 +0200, Erland Sommarskog   
    wrote:   
      
   >Gene Wirchenko (genew@ocis.net) writes:   
   >>      I gave a simple example of error return.  There may be more rows;   
   >> OrderBy is for presenting them in the correct order.  The additional   
   >> rows may be added one at a time so I went with a table.  Is there a   
   >> better way?   
   >   
   >I can only work from the example that I saw, and that looked funny.   
   >   
   >The normal procedure is to raise an error when there is one, and then   
   >exit. Only exceptionally do you care to produce multiple errors. Partly   
   >due to that the increase complexity induces a risk in the error-handling   
   >code. And when the error-handling code fails and produces an error,   
   >the user is left in the dark entirely. And often ourselves as the   
   >support and maintenance person tot.   
      
        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.   
      
   [snip]   
      
   >OK. Let it stop there, and don't deal whether this is an error or not.   
   >It's up to the outer layer to decide whether this is an error or not.   
      
        In some cases, SQL Server is going to have to decide that it is   
   an error.  (For example, if column validation fails.  While I do check   
   it in the front-end, I will also be checking in SQL Server.)  I want   
   to cover those cases.  This code is part of a first shot at it.  I do   
   want to cover error handling properly.   
      
   >>      IIUC, I read the rowversion value along with the rest of the row   
   >> and write it back with the rest of the update.   
   >   
   >You don't write it back - you can't modify a rowversion column. But your   
   >update looks like this:   
   >   
   >  UPDATE tbl   
   >  SET    ...   
   >  WHERE  keycol = @key   
   >    AND  tstamp = @tstamp   
   >  IF @@rowcount = 0   
   >  BEGIN   
   >     RAISERROR ('The row has been modified by another user', 16, 1)   
   >     RETURN 1   
   >  END   
      
        Ah, real code!    Thank you.   
      
   >>      That means that the rowversion value makes it to the front-end,   
   >   
   >Not necessarily. It could stay in the middle tier, but that depends on   
   >how you design that part of the application. If you keep it in the   
   >web server, you need to maintain state there, which I guess comes   
   >with its own set of problems. (I have never been involved with   
   >designing a web app, so I don't know what I'm talking about.)   
      
        That may be so, but you have some pieces of the solution that I   
   do not.  Thank you for sharing your expertise.   
      
   Sincerely,   
      
   Gene Wirchenko   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)