** NORMAS DEL FORO **
Inicio del foro Inicio del foro > Otros de Microsoft: Windows y Office > Visual Basic Clásico (VB3...VB6)
  Mensajes nuevos Mensajes nuevos RSS - Campo numérico distorsiona INSERT INTO
  Preguntas frecuentes Preguntas frecuentes  Buscar en el foro   Eventos   Registro Registro  Iniciar sesion Iniciar sesion

Tema cerradoCampo numérico distorsiona INSERT INTO

 Responder Responder
Autor
Mensaje
Medardo Ver desplegable
Colaborador
Colaborador
Avatar

Unido: 03/Marzo/2005
Localización: Cuba
Estado: Sin conexión
Puntos: 1987
Enlace directo a este mensaje Tema: Campo numérico distorsiona INSERT INTO
    Enviado: 07/Mayo/2015 a las 16:34
Hola
Tengo dos tablas llamadas 'tabVC' y 'tabVI' y quiero pasar los datos de 'tabVC' para 'tabVI'. Ambas tablas tienen la misma cantidad de campos y exactamente las mismas características cada campo. Lo único que las diferencian son los nombres de dichos campos. En ambas tablas existe un PRIMER campo que es numérico entero, con 0 (cero) decimales. El detalle está en que ese campo es el primero. Y es aquí donde comienza el problema.
La instrucción es la siguiente:
sSQLImp = "INSERT INTO tabVI " & _
                    "(Expediente, [1er Apellido], [2do Apellido], Nombres, " & _
                    "Sexo, [Carné Identidad], Edad, [Nivel Escolar], Especialidad) " & _
                    "SELECT IdDatosPers, DatosPersPriApell, DatosPersSegApell, DatosPersNombres, " & _
                    "DatosPersSexo, DatosPersCI, DatosPersEdad, " & _
                    "EscolarNivelEscolar, EscolarEspecialidad " & _
                    "FROM tabVC"
cnn.Execute sSQLImp

Fíjense que el campo 'Expediente' de la tabla 'tabVI' y el campo 'IdDatosPers' de la tabla 'tabVC' están posicionados en primer lugar. En este caso, la instrucción no hace nada.
Pero si eliminamos los campos 'Expediente' y 'IdDatosPers':
sSQLImp = "INSERT INTO tabVI " & _
                    "([1er Apellido], [2do Apellido], Nombres, " & _
                    "Sexo, [Carné Identidad], Edad, [Nivel Escolar], Especialidad) " & _
                    "SELECT DatosPersPriApell, DatosPersSegApell, DatosPersNombres, " & _
                    "DatosPersSexo, DatosPersCI, DatosPersEdad, " & _
                    "EscolarNivelEscolar, EscolarEspecialidad " & _
                    "FROM tabVC"
cnn.Execute sSQLImp

La instrucción se ejecuta perfectamente pero, como es lógico, sin incluir la numeración del campo 'Expediente'.
Ahora bien, si incluimos los campos 'Expediente' y 'IdDatosPers', pero en una posición diferente:
sSQLImp = "INSERT INTO tabVI " & _
                    "([1er Apellido], Expediente, [2do Apellido], Nombres, " & _
                    "Sexo, [Carné Identidad], Edad, [Nivel Escolar], Especialidad) " & _
                    "SELECT DatosPersPriApell, IdDatosPers, DatosPersSegApell, DatosPersNombres, " & _
                    "DatosPersSexo, DatosPersCI, DatosPersEdad, " & _
                    "EscolarNivelEscolar, EscolarEspecialidad " & _
                    "FROM tabVC"
cnn.Execute sSQLImp

Fíjense que ahora los campos 'Expediente' y 'IdDatosPers' si están incluidos pero en una posición diferente a la primera, en este caso, en segunda posición. Ahora sí, la instrucción se ejecuta completamente, es decir, aparece en la tabla 'tabVI' la numeración correspondiente al campo 'Expediente'.
Y aquí viene la pregunta:
¿Alguien tiene la explicación de este comportamiento?
Gracias

Saludos
Desde La Habana, Cuba
Medardo
Arriba
E. Feijoo Ver desplegable
Moderador
Moderador


Unido: 16/Abril/2004
Localización: España
Estado: Sin conexión
Puntos: 19948
Enlace directo a este mensaje Enviado: 07/Mayo/2015 a las 17:46
Normalmente en las SQLs de inserción, se indica (por la posición que ocupan en la definición de datos) los valores a insertar en ellos que también deberán ocupar esa 'posicion' en el apartado 'values' y los nombres que se utilicen para referirse a ellos es algo anecdótico (no es mas que una simple etiqueta), lo natural es esto:

Insert into AAA (campo1, campo2, campoN) Values (valor para campo1, valor para campo2, valor para campoN).

Solo si Access detectase uniformidad en tipo de datos y nombres se podría ser un poco menos restrictivo con las posiciones si se utiliza otra SQL como origen de datos (pero sin nominarlos, selección con asterisco para que Access pueda interpretar con libertad).
Arriba
Medardo Ver desplegable
Colaborador
Colaborador
Avatar

Unido: 03/Marzo/2005
Localización: Cuba
Estado: Sin conexión
Puntos: 1987
Enlace directo a este mensaje Enviado: 07/Mayo/2015 a las 21:34
Gracias Feijoo por su explicación. Interesante.
Saludos
Desde La Habana, Cuba
Medardo
Arriba
 Responder Responder
  Compartir tema   

Ir al foro Permisos de foro Ver desplegable