Código MySQL:
Ver original
{ }; { };
Las consultas hacen referencia a otras tablas, existen, pero no las puse acá por longitud del código...
Agradezco a quien me oriente
| ||||
![]() Buenos días, tengo una parte de un script que debería funcionar en MySQL, es algo muy básico, solo creación de unas tablas, poblarlas y finalmente unas consultas, pero requiero saber qué modificaciones debo hacer para que funcione también en SQLServer, Gracias!
Código MySQL:
Ver original Las consultas hacen referencia a otras tablas, existen, pero no las puse acá por longitud del código... Agradezco a quien me oriente
__________________ Suerte!! |
| ||||
Respuesta: Compatibilidad de código entre MySQL y SQLServer Bueno, hay varias cosas que corregir: 1) Los corchetes ({}) no tienen uso en MySQL. No sirven para nada y si los usas generarán errores de sintaxis. 2) Todo nombre de columna que contenga caracteres especiales u operadores, debe ser escrito entre acentos graves (`). 3) Toda cadena de texto debe ser puesta entre apóstrofos ('). 4) No confundir un apóstrofo (') con un acento grave (`). Son cosas diferentes. 5) Las comillas (") sólo se pueden usar como reemplazo de los acentos graves. Para ser usadas en textos hay que reconfigurar el modo del servidor. 5) Es preferible usar INNER JOIN y no los JOIN implícitos (la coma). 6) Ciertas clausulas y sintaxis propias de SQL Server no las entiende MySQL (de hecho tampoco las entienden otros DBMS). Evitalas. 7) Usa el manual de referencia... Eso es lo que hacemos todos al cambiar de DBMS.
Código MySQL:
Ver original
__________________ ¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente... "El problema es la interfase silla-teclado." (Gillermo Luque) Última edición por gnzsoloyo; 08/06/2013 a las 14:13 |
| ||||
Respuesta: Compatibilidad de código entre MySQL y SQLServer Quizá te refieras al nombre de las tablas, la tabla se llama Emp-Evt(vende), no pretendo hacer nada con los paréntesis. Y en la última consulta, que es una sola
Código MySQL:
Ver original Estoy trayendo los datos Incluido teléfonos que están en tablas aparte, donde los id_emp coincidan, pero los llamo como nombre_tabla.atributo = nombre_tabla2.atributo . Muchas gracias por las correcciones, la verdad soy bastante nueva en las bases de datos y todo me resulta confuso. |
| ||||
Respuesta: Compatibilidad de código entre MySQL y SQLServer Bueno, uno de los problema, precisamente, es que no es aceptable para MySQL usar caracteres reservados a código, lo mismo que palabras reservadas, como parte de las denominaciones. Los nombres de objetos de BBDD deben ser siempre alfabéticos o alfanuméricos, y MySQL no admite que inicien con números. Se recomienda como buena práctica que sólo se usen como caracteres extensivos la raya (_), o el de moneda ($). Fuera de esos, ninguno. Ergo, cambia el nombre de es tabla, en lo posible. Suponiendo poder cambiarla, las condiciones quedarían:
Código MySQL:
Nota: En ningún DBMS que yo conozca se acpta definir una relación como "A = B = C", en todo caso la transitoriedad se debe especificar como "A = B AND B = C", o bien como "A = B AND A = C".Ver original ¿Se entiende?
__________________ ¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente... "El problema es la interfase silla-teclado." (Gillermo Luque) |
| ||||
Respuesta: Compatibilidad de código entre MySQL y SQLServer Cita: El SQL no es un lenguaje de programación, sino un lenguaje de consultas. Pensé que así como en Java o C++ se podía esa relación Cita: No. Entre los diferentes DBMS las diferencias pueden ser sustanciales, y bastante amplias.es cierto que las diferencias de código para PostGreSQL y SQL server son solo de punto y comas y de algunos tipos de datos? Por lo pronto, todos los DBMS entienden lo que se denomina ANSI-SQL, es decir, el SQL estandarizado, que incluye las sentencias, estructuras fundamentales y algunas funciones. Pero todo lo demás difiere, y puede ser en mucho. Las funciones de fecha, concatenación, conversión, encriptación y control no son las mismas en todos los casos. Tampoco lo es siempre la sintaxis de los JOIN, que pueden tener diferente forma según cuál DBMS sea, o incuso cuál versión. Otro problema grande es que no existe un lenguaje procedural estandarizado, por lo que los stored procedures no son portables entre ninguno de ellos sin grandes adaptaciones. A esto hay que agregarle demasiadas cosas, pero en general uno se acostumbra a pasar de uno a otro, porque las estructuras fundamentales permanecen, y simplemente recurre a los manuales para definir cómo se hacen determinadas cosas en un DBMS en especial. Siempre hay algún modo.
__________________ ¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente... "El problema es la interfase silla-teclado." (Gillermo Luque) |
Etiquetas: |