Groups > comp.databases.ms-sqlserver > #1195

Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX

From	Gene Wirchenko <genew@ocis.net>
Newsgroups	comp.databases.ms-sqlserver
Subject	Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX
Date	2012-07-31 15:02 -0700
Organization	A noiseless patient Spider
Message-ID	<fflg18908osncqaa9ls5v0im6tcgmo5hv7@4ax.com> (permalink)
References	<b3ge181eguiicnuugkkak08jcpq3a0hmgd@4ax.com> <XnsA0A17141AB34CYazorman@127.0.0.1> <cj0g181jboo2s984amhsd95199t3cs5jes@4ax.com> <XnsA0A1DD643649CYazorman@127.0.0.1>

Show all headers | View raw

On Tue, 31 Jul 2012 21:45:49 +0200, Erland Sommarskog
<esquel@sommarskog.se> 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!  <slurp>  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

Back to comp.databases.ms-sqlserver | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Gene Wirchenko <genew@ocis.net> - 2012-07-30 19:37 -0700
  Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Gene Wirchenko <genew@ocis.net> - 2012-07-30 19:47 -0700
  Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Erland Sommarskog <esquel@sommarskog.se> - 2012-07-31 09:08 +0000
    Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Gene Wirchenko <genew@ocis.net> - 2012-07-31 09:26 -0700
      Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX "Bob Barrows" <reb01501@NOyahooSPAM.com> - 2012-07-31 14:12 -0400
        Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Gene Wirchenko <genew@ocis.net> - 2012-07-31 15:02 -0700
          Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Erland Sommarskog <esquel@sommarskog.se> - 2012-08-01 21:04 +0200
      Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Erland Sommarskog <esquel@sommarskog.se> - 2012-07-31 21:45 +0200
        Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Gene Wirchenko <genew@ocis.net> - 2012-07-31 15:02 -0700
          Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Erland Sommarskog <esquel@sommarskog.se> - 2012-08-01 20:59 +0200
            Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Gene Wirchenko <genew@ocis.net> - 2012-08-01 13:30 -0700
              Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Erland Sommarskog <esquel@sommarskog.se> - 2012-08-01 23:27 +0200
  Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX "Bob Barrows" <reb01501@NOyahooSPAM.com> - 2012-07-31 14:25 -0400
    Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Gene Wirchenko <genew@ocis.net> - 2012-07-31 15:02 -0700
      Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Jeroen Mostert <jmostert@xs4all.nl> - 2012-08-01 00:26 +0200
        Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Gene Wirchenko <genew@ocis.net> - 2012-07-31 17:43 -0700
          Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX "Bob Barrows" <reb01501@NOSPAMyahoo.com> - 2012-08-01 06:29 -0400
            Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Jeroen Mostert <jmostert@xs4all.nl> - 2012-08-01 20:40 +0200
              Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Erland Sommarskog <esquel@sommarskog.se> - 2012-08-01 21:02 +0200
              Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX "Bob Barrows" <reb01501@NOyahooSPAM.com> - 2012-08-01 16:02 -0400
          Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Jeroen Mostert <jmostert@xs4all.nl> - 2012-08-01 20:29 +0200
      Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Erland Sommarskog <esquel@sommarskog.se> - 2012-08-01 09:14 +0200
        Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Jason Keats <jkeats@melbpcDeleteThis.org.au> - 2012-08-04 18:14 +1000
          Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Erland Sommarskog <esquel@sommarskog.se> - 2012-08-04 21:15 +0200
            Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Jason Keats <jkeats@melbpcDeleteThis.org.au> - 2012-08-05 18:10 +1000
              Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Erland Sommarskog <esquel@sommarskog.se> - 2012-08-05 10:50 +0200
                Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Jason Keats <jkeats@melbpcDeleteThis.org.au> - 2012-08-06 00:03 +1000
                Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Erland Sommarskog <esquel@sommarskog.se> - 2012-08-05 20:21 +0200
                Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Jason Keats <jkeats@melbpcDeleteThis.org.au> - 2012-08-06 19:44 +1000
                Re: SSE2008: #Tables, Stored Procedures, Avoiding ActiveX Erland Sommarskog <esquel@sommarskog.se> - 2012-08-06 20:54 +0200

csiph-web