¿Existen diferentes lenguajes SQL? - ¿Existe vida en Marte?

[yomesmo]

Buenas (Por decir algo)

No sé si es que yo estoy gilipollas o es que esto es un cachondeo.

Acabo de exportar toda mi base de datos en access a MySQL, entendiendo que el lenguaje SQL es universal y que le repanpinfla que conectes contra una base de datos en access, SQL u Oracle.

Pues parece que no es así, abro mi web y recibo por todas partes mensajes del tipo:


[TCX][MyODBC]You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '() AND CHA_MENU <>'Encuestas' ORDER BY DAT_NAME ASC' at line 1



Por poner un ejemplo, tengo una sentencia que dice asÍ:

rsChannels.Source = "SELECT *, (SELECT COUNT(*) FROM DATAS WHERE DAT_CATEGORY = CAT_ID AND DAT_APPROVED=1 AND DAT_EXPIRED > DATE()) AS DAT_COUNT FROM CATEGORIES, CHANNELS WHERE CAT_CHANNEL = CHA_ID AND CAT_CHANNEL = " + Replace(rsChannels__varChannel, "'", "''") + " AND CAT_PARENT = 0 ORDER BY CAT_NAME ASC"

Y me dice que hay un error de sintaxis, cuando con access siempre funcionó correctamente (Es el código que genera el Dreamweaver)

Preguntas:

1.- ¿Existen distintos lenguajes SQL?
2.- Si es así, ¿Cada formato de bases de datos tienen un lenguaje propio?
3.- ¿Existe vida en Marte?

Gracias

[josemi]

Hola,

1.- Si, existen distintas versiones del estandard SQL. Es universal, pero con dialectos incompatibles entre si, y algunas BD no lo conocen completamente y lo mezclan con su idioma nativo.
2.- Cada BD soporta ciertos tipos de SQL, añades funciones propias, cambia alguna sintaxis, no soportan ciertas funcionalidades (subconsultas, procedimientos alamcenados).
3.- Si, pero o esta muerta o es microscopica

Saludos.

[yomesmo]

Gracias Josemi, es justo la respuesta que no queria escuchar, pero siempre he preferido la verdad dura y tal y como es a la mentira compasiva...

Eso es una auténtica locura para los programadores, hay que aprender la sintaxis de cada tipo de BD. No entiendo como no se ha unificado en un solo formato.

¿Sabes donde puedo encontrar algún manual aceptable en castellano sobre el MySQL?,Ya sabes, algo que no me vuelva más tonto de lo que ya estoy y que sea entendible.

PD: Me estan temblando las pelotas solo de pensar la de horas que me va a tocar dedicar para acoplar la mierda del código a MySQL (Veo que el problema más gordo es con las sentencias que incluyen otras en si mismas)

Más que de sufrir y de sufrir...

[BrujoNic]

El SQL es un estándar... Lo que pasa entre motores de BD es el uso de funciones propias entre unas y otras. Un ejmplo es el mismo Access (que a mi parecer NO es una BD). Si lo instalas en inglés tenes unas sentencias y en español otras (traducidas).

Hay declaraciones de tipos de datos que no existen en otras y lo más importante las funciones propias.

Cuando se va a migrar de un motor de BD a otro, lo primero que se debe investigar en la compatibilidad de los tipos de campos y si alguno no es compatible, cambiarlo primero en la BD original. Ejemplo, si access maneja los campos fecha en formato DDMMAAAA y debo pasarlo a MySQL, debo ver como almacena ese tipo de campo AAAAMMDD. Lo que hago es crear un campo string o texto, pasando la fecha al formato que interpreta el otro motor. No es de complicarse es solo de aprender las funciones de otra BD y entre más estándares se usen, más fácil va a ser la migración.

Manual de MySQL

[Mithrandir]

Y así como es un estandar hay quien lo sigue y quien no.

Al momento el estandar mas estandar (valga la redundancia) es SQL-92, que es el que la mayoría de las DB soporta (si mal no recuerdo existe SQL-98, pero casi no es mencionado). Claro, define unas funciones basicas, pero de ahi cada fabricante lo deforma y adapta para que se acople a su modelo.

Hay RDBMS que lo soportan parcialemente (como MySQL) y algunas que ni siquiera son RDBMS (como Access, que es mas bien una herramienta)

Por ejemplo el query que utilizas parece un subquery (bastante bizarro) que MySQL dificilmente soportará. MySQL tiene soporte para subquerys hasta hace poco tiempo, pero no se que tan flexible sea