Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

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

Re: Enforcing an Order to Validation

Show all headers | View raw

On Fri, 11 May 2012 09:01:22 +0200, Erland Sommarskog
<esquel@sommarskog.se> wrote:

>Gene Wirchenko (genew@ocis.net) writes:
>>      One of the issues that I have with database errors is the
>> disconnect between them and the frontend.  
>
>Yes, down in the database, you cannot really tell what error the user did.
>All you can tell is that a constraint etc was violated.

     I know.  I want to connect the two.  I wish it were easier.

>Particularly, if you want error message that helps the user, constraints
>are not your guy.

     I am fine with having to convert.

>>      I am trying to find out what is the guaranteed behaviour.  That
>> is safer.
>
>I gave it some more thinking, and there is hardly any guaranteed order.
>There is an optimizer and it makes the actions in the order which is the
>most efficient.

     I expected that would be the case, but I decided to ask, just in
case.

>>      I think that statement should be that the database should never
>> permit such, but the application should be free to do no error
>> checking.  The application also doing error checking makes for a more
>> friendly app, but I would prefer correctness FIRST.
> 
>Let me make it clear again: the error messages that are produced by 
>SQL Server when a constraint is violated are not helpful for the user.
>At best you can trap and interpret them. But that is difficult.

     I do not see why, at least, for my use.  Suppose a Postal Code is
invalid.  That column's constraint fails.  If I send back tothe
front-end that Postal Code has an error, I simply issue an error
message that the Postal Code is invalid.

     What difficulty are you thinking of?

>And since the error messages are useless to the user, it's completely
>irrelevant in which order SQL Server checks the constraints.

     The order of the *errors* -- not error messages -- is important.

>Error messages from stored procedures and trigger checks are a different
>matter, here you have control. Then again, down in the trigger all
>you can tell that a column has an illegal value, but you don't know
>where in the form the user went wrong. You don't even know if there is
>a form.

     I will inmy design.

>Finally, permit me to point out that the application can implement error 
>checking more than one way. If a column only permits the values A, B and C 
>the application will of course not expose a text box, but a drop-down or a 
>ratio button.
 ^^^^^
     "radio".

     No, not "of course".  For data entry speed, the current app down
not use dropdowns, and I expect this to continue with the Web
front-end version.

     The front-end can issue whatever error message is appropriate to
it once it knows that there was an error on a given column/field.


     Thank you for your time and comments.  Aside from alternatives
suggested, this helps me make sure that I really want things the way I
want them.

Sincerely,

Gene Wirchenko
    

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

Thread

Enforcing an Order to Validation Gene Wirchenko <genew@ocis.net> - 2012-05-10 12:42 -0700
  Re: Enforcing an Order to Validation Erland Sommarskog <esquel@sommarskog.se> - 2012-05-10 23:47 +0200
    Re: Enforcing an Order to Validation Gene Wirchenko <genew@ocis.net> - 2012-05-10 15:05 -0700
      Re: Enforcing an Order to Validation Erland Sommarskog <esquel@sommarskog.se> - 2012-05-11 09:01 +0200
        Re: Enforcing an Order to Validation Gene Wirchenko <genew@ocis.net> - 2012-05-11 09:50 -0700
          Re: Enforcing an Order to Validation Erland Sommarskog <esquel@sommarskog.se> - 2012-05-11 22:29 +0200
            Re: Enforcing an Order to Validation Gene Wirchenko <genew@ocis.net> - 2012-05-11 22:10 -0700

csiph-web