É bem simples, quando vc "confia" na conevrsão implícita e automatica, vc corre dois riscos :
1. a conversão TANTO pode ocorrer à esquerda ou à direita dum operador de comparação, por exemplo imagine o código abaixo : ... WHERE colunanumérica = '45' ... nesse caso o bd Oracle TANTO pode escolher converter a string '45' para o número 45 e fazer a comparação com a coluna numérica ** OU ** pode optar por converter a coluna numérica para string,e aí comparar string com string. O risco é que SE o banco optar por converter a coluna numérica para string E haver um índice nela, obviamente o índice contém NÚMEROS e não strings, pode não ser usado... 2. conversão implícita necessariamente ** UTILIZA ** as variáveis de ambiente do cliente conectado no banco, que TRANQUILAMENTE podem estar diferentes das do banco e/ou do assumido no programa. Imagine que vc conecta no banco com um cliente configurado para datas no formato DD/MM/YYYY e executa um SQL tipo : ... WHERE colunadate = '15/01/2007' ... a query funcionará OK, mas se esse MESMO programa enviar esse MESMO SQL a partir duma máquina-cliente setada com OUTRO formato default de data (digamos, 'MM/DD/YYYY') o banco vai "achar" que '15' é o mês, vai dar ERRO..... Programa que confia em defaults de ambiente CEDO ou TARDE acaba "estourando", é uma prática COMUM e RECOMENDADA de programação defensiva de escrever algo como : ... WHERE colunadate = to_date('15/01/2007', 'dd/mm/yyyy') ... aí esse código NÃO falha seja qual for o default da sessão-cliente. ==>> essas questões NÂO foram inventadas por mim, no manual de SQL Reference a Oracle o diz com todas as letras : "Data Conversion Generally an expression cannot contain values of different datatypes. For example, an expression cannot multiply 5 by 10 and then add 'JAMES'. However, Oracle supports both implicit and explicit conversion of values from one datatype to another. Implicit and Explicit Data Conversion Oracle recommends that you specify explicit conversions, rather than rely on implicit or automatic conversions, for these reasons: SQL statements are easier to understand when you use explicit datatype conversion functions. Implicit datatype conversion can have a negative impact on performance, especially if the datatype of a column value is converted to that of a constant rather than the other way around. Implicit conversion depends on the context in which it occurs and may not work the same way in every case. For example, implicit conversion from a datetime value to a VARCHAR2 value may return an unexpected year depending on the value of the NLS_DATE_FORMAT parameter. Algorithms for implicit conversion are subject to change across software releases and among Oracle products. Behavior of explicit conversions is more predictable. " []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Myria Salvino <[EMAIL PROTECTED]> escreveu > > Ola Amigos > > Por favor que puder ajudar : > > Por que usar conversao implicita em pl/sql 'e uma pratica ruim de programacao?? > > Obrigada > > My > > Flickr agora em português. Você clica, todo mundo vê. Saiba mais. > > [As partes desta mensagem que não continham texto foram removidas] >