Pode-se montar um dicionário com os erros mais prováveis e para os não catalogados usa-se uma mensagem genérica onde exibe-se a mensagem de erro original.

Pode-se também enviar por e-mail ao responsável pelo sistema o erro ocorrido, com a mensagem original e tudo.

Sds,

Frederico.

>Rodolfo,
>O PCC tem razão, pode ocorrer um erro que vc não tenha visto, então como fica no cliente ?
>O problema é que ninguem que eu conheça traduziu o conjunto de mensagens de erro do SQL Server, ninguem mesmo, inclusive isto é postado em varios foruns de SQL Server no Brasil, onde alguem sempre solicita uma copia traduzida da relação de erros, e nunca há retorno.
>O motivo é bem simples:
>A) são mais de 8.000 tipos de mensagens de erro
>B) se a MS aplicar um Service Pack, pode aparecer mais um tipo de erro ou a mensagem pode ser alterada.
>
>A sua ideia não é ruim, mas se uma outra parte da mensagem form diferente e o 'Clientes_CPF_Unico' for apresentado, vc estaria apresentando uma mensagem errada.
>
>Veja eu uso o SQL Server e acho que ele tem alguns defeitos graves, entre eles é a falta de um BEFORE TRIGGER e de um campo DATA (somente data, pois todos os demais RDBMS tem só o SQL Server Não).
>Outro problema que vejo no desenvolvimento do SQL Server, é que as mensagens são feitas para um DBA e não encontrei forma de fazer mensagens do SQL serem "amigaveis" para os desenvolvedores, para que se possa apresentar algo que seja apresentavel ao usuário final.
>Portanto o que falta ao SQL Server neste caso é poder definir uma mensagem de erro amigavel para as constraints.
>
>Mas se desejar vc pode começar um projeto para traduzir todos os erros do SQL Server para o portugues e de forma amigavel, assim que estiver pronto vc informa aonde podemos obter uma cópia.
>Prometo que vou agradecer muito :))
>
>Agora falando sério...
>Eu até hoje só vi o controle ser feito no front-end ou via SP no SQL Server para que se possa controlar a situação.
>Eu tambem passei por isto e como não encontrei, resolvi usar SP para ter controle REAL da situação, já que não posso contornar a mensagens de constraint.
>
>[ ]'s
>Peter
>
>
>>Peter,
>>
>>Estava pensando no seguinte... Observe as duas mensagens de erro abaixo:
>>
>>1526 - [Microsoft][ODBC SQL Server Driver][SQL Server]INSERT statement conflicted with COLUMN CHECK constraint 'Clientes_Cfp_Formato'. The conflict occurred in database 'Estudo', table 'Clientes', column 'Cpf'.
>>
>>1526 - [Microsoft][ODBC SQL Server Driver][SQL Server]Violation of UNIQUE KEY constraint 'Clientes_CPF_Unico'. Cannot insert duplicate key in object 'Clientes'.
>>
>>Nestes dois casos, eu recebo o nome da constraint que causou o erro: Clientes_Cpf_Formato e Clientes_CPF_Unico - certo?
>>
>>Bom... Pensei em criar uma tabela interna do sistema (ou até mesmo no SQL Server) com a seguinte estrutura:
>>

>>Regra                          Mensagem
>>Clientes_Cpf_Formato           CPF/CNPJ inválido
>>Clientes_CPF_Unico             CPF/CNPJ duplicado
>>

>>Depois, isolo o nome da constraint que causou o erro. Faço um select na tabela SQLErros e acho a mensagem que irá para o usuário.
>>Se não encontrar a REGRA (ou o campo mensagem estiver vazio), mostro a própria mensagem do SQL pro usuário e gero um registro em branco nesta tabela de erros. Assim, basta eu filtrar as mensagens em branco para saber quais Regras já aconteceram e eu não fiz a mensagem de erro ainda.
>>
>>Estou começando no SQL e não sei se vai acontecer alguma situação onde isso não funcionaria... Você sabe me dizer?
>>
>>Para facilitar, pensei em criar nomes para constraint do tipo: ERRO_Clientes_Cpf_Formato_ERRO e usar StrExtract com os limitadores ERRO_ e _ERRO para pegar a string que vou procurar na tabela SQLErros!
>>
>>[]s!