Como hacer para que al insertar los registros primary key que se encuentran duplicado

[heruxz]

Buenas a todos!

El problema que tengo es que estoy desarrollando un sistema en vb.net 2010 en el cual se importa desde un archivo de excel hasta la base de datos en mysql una gran cantidad de registro a diario, ya tengo las distintas tablas armadas con su debida relacion, una de esas tablas tiene un campo que tiene el codigo de una empresa que es el campo clave de una de las tablas y en el archivo de excel se repite el mismo codigo de las empresas muchas veces, como puedo hacer para que al momento de importar el archivo de excel a mysql me guarde los campos que no son primary key y que si el primary key ya esta guardado lo ignore y siga con los demas registros... Es decir algo q tenga como la siguiente funcionalidad: Si primary key esta repetido guarde los registros que no son campos claves y salte para la proxima fila de datos que se encuentran en el archivo de excel.

Existe alun Query con esta funcionalidad?

espero me entiendan y me puedan ayudar... Gracias

[gnzsoloyo]

espero me entiendan y me puedan ayudar...

Entenderte, se entiende. Pero hay algunos detalles que debes considerar, y muy probablemente debas replantear la forma de tu fuente de datos.
Lo que estás tratando de hacer es insertar varias cosas que son diferentes, y se está produciendo lo que se denomina "datos sucios", y lo que en realidad debes hacer es precisamente limpiar esos datos par que los ingresos sean correctos. No crear un proceso de inserción que los limpie.
Por lo que dices, tu Excel contiene tanto los datos de alta de las empresas, como los datos de actualización de las mismas. Además contendría datos correspondientes a otras tablas, dependientes de esas empresas.
Por lo pronto, debes separar las tres cosas:
1) Las tablas base, con un Excel que contenga sólo los datos a dar de alta en las tablas de Empresa u otras que puedas necesitar.
2) Las actualizaciones a las tablas base, a fin de realizar un proceso de UPDATE correcto.
3) Las tablas secundarias, donde uses los datos dependientes de las tablas base.

No existe forma de hacer una transferencia de datos con una única consulta y que haga estas tres cosas. Se deben hacer en momentos diferentes, especialmente entre las dos primeras acciones y la tercera. Ambas deben estar completamente terminadas antes de hacer la tercera, o todo fracasará.

Si bien existe una sentencia que reemplaza un registro con otro, esto haría que en el registro de la Empresa desaparezcan todos aquellos datos que no ingresen en la nueva alta. Además, este proceso no funciona si ya existen en la tabla secundaria registros que dependan de la empresa a reemplazar.

Otras opción sería usar el INSERT IGNORE INTO..., pero eso simplemente evitaría que se ingresen datos de una empresa que yá exista en la tabla, y no admitiría actualizar campos.

Es posible que se pueda hacer un stored procedure que haga alternativamente las altas y los update correspondiente a las Empresas, pero lo que sí es seguro es que no podrás dar el alta a las tablas de segundo orden sin que las tablas base estén completa.

Si lo pudieras hacer se generaría una peligrosísima falla de integridad referencial y consistencia de datos.

¿Se entiende el planteo?

[heruxz]

gnzsoloyo muchas gracias por tu respuesta, pero no entendi mucho lo que pasa es que estoy comenzando con esto de la programacion.

Ahora te pondre un ejemplo facil de entender como seria el contenido del archivo de excel que necesito importar a diario:

Codigo_Cliente Nombre Direccion Vendedor producto
1a leandro argentina carlos peras
1a leandro argentina jose manzanas
1b juan peru carlos manzanas
1a leandro argentina carlos uvas

Ahora supongamos que este sea el archivo excel, como ves el cod_cliente para leandro se repite en varias ocasiones, si importo este archivo al datagrid se vera de igual manera y al hacer el insert into a la tabla cliente almacenara el primer registro con exito pero cuado toque guardar el segundo registro me dara el error de que el cod_cliente ya esta registrado y no almacenara lo demas, lo que quiero es que en el segundo registro asi el cod_cliente este repetido este lo ignore y guarde los demas campos en la BD...

[gnzsoloyo]

Codigo_Cliente Nombre Direccion Vendedor producto
1a leandro argentina carlos peras
1a leandro argentina jose manzanas
1b juan peru carlos manzanas
1a leandro argentina carlos uvas

Ahora supongamos que este sea el archivo excel, como ves el cod_cliente para leandro se repite en varias ocasiones, si importo este archivo al datagrid se vera de igual manera y al hacer el insert into a la tabla cliente almacenara el primer registro con exito pero cuado toque guardar el segundo registro me dara el error de que el cod_cliente ya esta registrado y no almacenara lo demas, lo que quiero es que en el segundo registro asi el cod_cliente este repetido este lo ignore y guarde los demas campos en la BD...

El problema que tienes es que una tabla en Excel de semejantes características no sirve para realizar altas de una tabla base. No sirve porque precisamente esa tabla muestra redundancia perniciosa de datos, la cual se origina en que los datos de la misma componen un reporte... y un reporte no es fuente de datos para la base si no se hace un procesamiento previo.
Lo que debes hacer es diseñar un proceso tal que realice la extracción de los datos desde el archivo en Excel, y que vaya incorporando los datos extraídos en sus tablas destino, en el orden correcto y guardando los datos ya normalizados.
Desde ya que no existe una consulta que pueda hacer eso. Como mucho se debe diseñar por medio de stored procedures, pero no es una tarea simple.
Ahora bien, el hecho de que tengas problemas de unicidad de Pk en un contexto parecido a ese a mi me sugiere que el diseño de la tabla pueda ser incorrecto en alguna forma.
Me explico: Una tabla que almacene reportes, no puede jamás darte error de clave duplicada, a menos que la clave esté mal diseñada, y que incorpore cosas que no están correctamente analizadas. Eso sería porque un reporte es una tabla de datos ya consolidados, y el único identificador que poseen es el ID de cada línea. Pero no otros.
Lo que si pueden tener son FK que apunten a las tablas origen de datos con las que se relacionan (Empresa, Cliente, Documento, etc.), pero siendo relaciones 1:N, no deberían generar ese inconveniente.
Distinto es si intentas tomar los datos de la Empresa desde un reporte. Es obvio que habrá repetición de la PK, porque ese dato tiene cardinalidad N. En ese caso primero tienes que seleccionar los distintos para poder ingresarlos en la tabla base.
Pero tienes que tener en cuenta que todas esas extracciones de datos deben ser previas a cualquier ingreso de datos consolidados (reporte), o de lo contrario se pueden generar inconsistencias no detectadas.tes)
¿Se va entendiendo el problema a resolver?

[heruxz]

gnzsoloyo con la explicacion que me diste si entendi muy bien lo que me tratas de dar a entender, por lo que buscare alguna otra solucion... muchas gracias

[gnzsoloyo]

me alegro que se haya entendido.
Te comento una experiencia: Yo hace unos cuatro años trabajé en un proyecto donde se recibían cinco tablas, de las cuales una era una "bitácora" de eventos en el transcurso del tiempo. De esa bitácora debíamos tomar los datos para la gestión de reportes de una flota completa de vehículos, tomando en cuenta que era una bitácora distinta por cada vehículo, cada quince días.
Obviamente, no podíamos tomar los datos puros, porque presentaban el mismo tipo de problemas tuyo.
Lo que hicimos lo logramos en dos etapas:
- Primero, creamos tablas temporales para cargar los archivos CSV que recibíamos. Sobre esas tablas ejecutamos un SP (que nos llevó dos meses diseñar), que realizaba etapa por etapa, las extracciones de datos y la normalización necesaria.
Al final del SP, los datos de esas cinco tablas en CSV quedaban repartidos en... 38 tablas diferentes.
Esto lo hicimos únicamente para poder iniciar el diseño del proceso que íbamos a verificar.

- Luego, partimos el SP en diferentes SP, y algunas parte de la lógica usada la transferimos a la aplicación (en .NET), dejando en SP solamente aquellas partes que eran exclusivo dominio de la base.
Al final logramos que la aplicación tomase los cinco archivos de cada paquete, los cargase en un DataSet en 17 tablas básicas, realizando previamente algunas validaciones de datos ne la base, y luego la misma aplicación cargaba tabla por tabla todo en una sola transaction.
No fue fácil. Llevó muchas horas de desarrollo, e incluso a mitad de camino tuvimos que realizar re-ingenierías en el diseño de datos, pero al final el sistema terminaba cargando millones de registros de más de 200 bitácoras en poco tiempo.

No te desesperes. Hazte un plan de desarrollo y ve parte a parte.
La tarea puede ser larga, pero se puede lograr.