From: genew@ocis.net   
      
   On Fri, 11 May 2012 09:01:22 +0200, Erland Sommarskog   
    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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)