Diferencia increible entre Oracle y SQLserver

Gabriel me mostró un problema con una webtransaction generada con .NET. Era algo muy sencillo y que funcionaba bien en SQL Server y mal con Oracle, pues no estaba funcionando correctamente cuando habia uno de los elementos de la clave C(2) que tenia 2 blancos.

Hicimos la prueba sencilla
create table tabla (Campo Char(2))
insert into tabla values(' ') -- Inserto un registro con dos blancos.


Oracle 9i

SQL Server 2000

select * from tabla where campo=' ' --dos blancos

1 registro seleccionado

1 registro seleccionado

select * from tabla where campo=' ' --un blanco

1 registro seleccionado

1 registro seleccionado

select * from tabla where campo='' --sin blancos

0 registro seleccionado

1 registro seleccionado

Es entendible que los DBMS tengan diferencias en la sintaxis de algunas sentencias complejas o en los dialectos utilizados para la creacion y modificacion de las tablas, pero parece poco creible (o debo decir serio) que difieran en los resultados de las consultas.

Comentarios

  1. Soy desarrollador de software, utilizo SQL Server y ahora estoy aprendiendo Oracle..

    La verdad que no deberían de darse este tipo de diferencias, pero tambien esto pudiera ocurrir por alguna configuración del motor.

    Un ejemplo clasico sobre diferencias en la configuración del motor es el del "auto commit", el cual el SQL Server tiene habilitado por default mientras que el Oracle lo trae deshabilitado.

    ResponderBorrar
  2. Dio:
    Hay muchas diferencias que son debidas a configuraciones.
    Esas las entiendo y hasta puedo compartir muchas.

    La que planteo, no depende de configuraciones, por lo menos hasta lo que yo pude encontrar.

    Gracias por el comentario...

    Enrique

    ResponderBorrar
  3. El tema es que en Oracle '' (sin espacios) equivale a NULL.

    ResponderBorrar
  4. Anonimo:
    Gracias por el comentario.

    Lo que es increible es que funcionen diferente. Siendo dos bases de datos muy difundidas, no se porque no se pueden poner de acuerdo en que las sentencias SQL devuelvan lo mismo.
    Seguramente existan motivos historicos para que tengan diferencias, pero igual no lo entiendo, como despues de tantos años, no se ha podido estandarizar esto.

    Si hablamos de manejos de fechas, de funciones de string, de manejo del NULL, hay otras diferencias mucho "peores"..

    Enrique

    ResponderBorrar
  5. Enrique tengo curiosidad en algo, dices que funciona "mal" en Oracle, porque la sentencia no devuelve filas y SQL Server si. Pero si planteamos la consulta semanticamente seria "Obtenga todas las filas de la tabla "tabla" donde el campo "campo" este vacio" asumiendo que la convención comillas simples vacias signifique no hay valor en este campo. Pero al efectuar un conteo de filas que no cumplan la condición y otro que si te da el numero total de registros de la tabla o te da mas? Y si obtienes la longitud del campo? que pasa en cada motor? la pregunta que más me intriga es, independientemente de la plataforma, como requisito funcional o regla de negocios dos espacios en blanco es lo mismo que un espacio en blanco y que una cadena de caracteres vacios? fijate en esta página http://msdn.microsoft.com/es-es/library/ms172138.aspx Sobre las plataformas... en mi humilde opnión la manera como SQL Server lo maneja es buena pero el concepto de cadenas de string de longitud cero me parece irrelevante en la vida real. En el articulo http://www.devx.com/dbzone/Article/32852 lo hacen ver importante con el ejemplo del segundo nombre... pero al sistema le importa si sabes o no el 2do. nombre? no le importa solo le importa que no lo tienes para digitarlo y la hora de la verdad en un caso de negocio quien pregunta cuantos segundos nombres no sabemos en la empresa es un concepto humano que no es relevante en el modelo ni de negocios, ni funcional y mucho menos relacional

    ResponderBorrar
  6. Alvaro:
    No opino sobre lo que esta bien o mal en mi post. Solo indico que me resulta poco creíble que una sentencia tan sencilla la resuelva de forma diferente en los dos DBMS mas usados...

    ResponderBorrar
  7. Muy válida tu aclaración...(En tu primer comentario textualmente decía "funcionaba bien en SQL Server y mal con Oracle") Concuerdo contigo en que los estándares se hicieron por un motivo, pero al final el vil verde (el dinero) tiene una influencia grande sobre todal las cosas, Oracle seguirá buscando que los que usan su DB sigan usando mas productos Oracle y lo mismo podemos decir de Microsoft... Por eso creo que es mejor tener un pie en cada lado y por ahí derecho un poquito de SAP (ABAP) no cae mal...

    ResponderBorrar
  8. Alvaro:
    Lo que digo es que funciona mal en Oracle, es un programa (que en Genexus se le llama Transaccion, que no es una trasaccion del DBMS).
    Este programa si funcionaba mal en Oracle y bien en SQLServer, porque esperaba un registro y no lo estaba trayendo.
    Ahora, que es lo que debe devolver un DBMS en este tipo de consultas, no me preocupa, pero si deberia ser lo mismo.

    La teoria relacional tiene un trasfondo matematico preciso y con este tipo de detalle de implementacion, toda su argumentacion se viene al piso.

    ResponderBorrar
  9. Claro... ya entendí. Viejo me parece una nota el concepto que están manejando con Genexus... no conocía este tipo de solución... tienen algun cliente en Colombia? Este concepto es propietario, quiero decir lo inventaron allá UY?

    ResponderBorrar
  10. GeneXus es un invento uruguayo.
    No trabajo en la empresa que lo invento (www.genexus.com)
    El distribuidor en Colombia se llama

    AMAZING COLOMBIA S.A.
    Tipo: Distributor
    Servicios Ventas
    País COLOMBIA
    Tel.: +57 1 657 9069 +57 1 657 8240

    URL: http://www.co.amazingglobal.com

    ResponderBorrar

Publicar un comentario

1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.

Entradas más populares de este blog

La nefasta influencia del golero de Cacho Bochinche en el fútbol uruguayo

Aplicación monolítica o distribuida?

Funcionalidades de GeneXus que vale la pena conocer: DATE Constants.