From: esquel@sommarskog.se   
      
   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.   
      
   >      (I do not know what to call the level that is between the browser   
   > and SQL Server.  It a) receives the HttpXMLRequest and queries SQL and   
   > b) receives the resultset from SQL Server and packages it for the   
   > browser.  What is it called?  I will now refer to it as Glue.)   
      
   I usually call that a "web server". A more general term is "middle tier",   
   which also can cover forms application that does not communicate directly   
   with the database server.   
      
   >      IIUC, you are saying that if I try to return more than one table?   
   > Not the case.  Either I return the table data requested, or I return   
   > error data.  I do not even know how I would return more than one   
   > resultset.  Is it even possible?   
      
   Yet the procedure you posted can potentially produce two result sets!   
      
   Yes, you can easily produce multiple result sets from SQL Server, and   
   you can easily test this in SSMS. But not all applications handle   
   multiple recordsets well, partly due to flaws in the client API.   
   ADO .Net does a good job in this area. (In difference to old ADO.)   
      
   >      No.  The purpose of the procedure is to return the row or that   
   > there is not one.  If the row is there, the procedure should return   
   > it.  I need the data to populate the form.   
      
   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.   
      
   >      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   
      
   >      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.)   
      
      
      
   --   
   Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se   
      
   Links for SQL Server Books Online:   
   SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx   
   SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)