Dump DB

[bohemianproductions]

Buenas tardes.
Espero me puedan ayudar con estas 2 consultas:

1.- ERROR INSERT INTO
Con el archivo que adjunto (lo pego al final) exporto mi base de datos, cuando trato de importarlo a mi phpMyAdmin 4.3.8 me sale el siente mensaje de error:

Error en la linea de 838511: INSERT INTO jos_finder_terms VALUES('26', 'a dise�ar se', 'a dise�ar se', '0', '1', '1.4', 'A3262', '3', 'es');
Consulta: INSERT INTO jos_finder_terms VALUES('26', 'a diseñar se', 'a diseñar se', '0', '1', '1.4', 'A3262', '3', 'es')
MySQL: Duplicate entry 'a dise' for key 'idx_term'

¿Qué es lo que tiene mal el archivo que exporta la DB con dicho error?.

2.- ¿Por qué no se muestra el avance del trabajo?

Muchas gracias por su ayuda.
Que tengan un buen día.

------------------------------------------------------------------------------------------------------

Es el archivo con nombre: dump_db.php
Lo pueden descargar en: [URL="https://mega.co.nz/#!xhBn2CjI!TjUpdL3vPoRcwUSPchN5dWLki3e9wMMUYOh6KV6 Cen8"]https://mega.co.nz/#!xhBn2CjI!TjUpdL3vPoRcwUSPchN5dWLki3e9wMMUYOh6KV6 Cen8[/URL]

[gnzsoloyo]

¿Qué es lo que tiene mal el archivo que exporta la DB con dicho error?.

El charset...
phpMyadmin espera recibir un archivo plano en el charset UTF-8, y aparentemente está recibiendo algo que está o en LATIN1, o bien en UNICODE. Ninguno de los dos es el que corresponde.
Usualmente es algún paso al manejar el dump, o bien un defecto de configuración en el FTP del servidor donde se lo intenta subir.
Ya han consultado recientemente por un problema parecido, y al final lo resolvieron en el foro de WebServers, ya que era un tema de configuración del servidor.

[bohemianproductions]

Hola,
Gracias por tu respuesta.
¿No tiene que ver con INSERT INTO?

[gnzsoloyo]

¿Entendiste lo que dije del CHARSET?

[bohemianproductions]

Iniciado por gnzsoloyo

El charset...
phpMyadmin espera recibir un archivo plano en el charset UTF-8, y aparentemente está recibiendo algo que está o en LATIN1, o bien en UNICODE. Ninguno de los dos es el que corresponde.
Usualmente es algún paso al manejar el dump, o bien un defecto de configuración en el FTP del servidor donde se lo intenta subir.
Ya han consultado recientemente por un problema parecido, y al final lo resolvieron en el foro de WebServers, ya que era un tema de configuración del servidor.

Hola.
¿Cómo podría agregar lo referente al charset='utf8' en el archivo dump_db.php?
Gracias por tu respuesta.

[gnzsoloyo]

No es algo que puedas "agregar" exactamente. Es el modo que se https://es.wikipedia.org/wiki/Codifi..._de_caracteres, ya que entenderás que las letras, los caracteres, no existen en realidad en la computadora. Son códigos binarios que luego se traducen para ser visualizados.
El problema lo veo por este lado:

INSERT INTO jos_finder_terms VALUES('26', 'a dise�ar se', 'a dise�ar se', '0', '1', '1.4', 'A3262', '3', 'es');

Esos símbolos suelen aparecer solamente si el charset que llega la base es diferente al que espera, cosa que puede pasar si usa UNICODE o LATIN1, dado que la base no espera eso.
Si ese es el problema, y el archivo origen no ha sido editado o modificado luego de realizarse el backup, usualmente es un problema de configuración en el FTP. Y eso no lo vas a corregir simplemente agregando o sacando cosas del archivo.
¿Ese bloque aparece así en pantalla, o es algo que copiaste tu?

Ahora bien, yendo al mensaje de error que recibes, es posible que haya otro problema diferente:

MySQL: Duplicate entry 'a dise' for key 'idx_term'

Esto otro es puntualmente un problema del backup.
Normalmente un backup no debería generar ese mensaje, si la restauración incluye la creacion misma de la base. Pero es un mensaje habitual cuando lo que está haciendo es una restauración de DATOS sobre una base que ya los tiene.
Es muy común que las tablas tengan campos ID autoincrementales, y que estos sean la PK, especialmente en MyQSL. No es una buena practica, pero es lo que suelen hacer.
El problema es que un campo AI, cuando la tabla ya tiene datos, ya tiene ciertos registros con el valor de ID, y si intentas hacer una restauración de datos desde un archivo, y la base origen de ese archivo contiene todos los ID iniciales, es muy habitual que estés intentando agregar registros a una tabla con un valor de ID que esa base ya tiene en esa tabla.
Si recuerdas, una PK debe ser única, y por tanto si intentas insertar un registro con un numero que ya existe en esa tabla se disparará un error de clave duplicada... que es lo que te está pasando.

¿Se entiende?

Nota Bene: Todo esto es OFF TOPIC en el foro de PHP. Es un problema puramente de MySQL, y deberías haber posteado la pregunta en ese foro...

[bohemianproductions]

Iniciado por gnzsoloyo

No es algo que puedas "agregar" exactamente. Es el modo que se [url]https://es.wikipedia.org/wiki/Codificaci%C3%B3n_de_caracteres[/url], ya que entenderás que las letras, los caracteres, no existen en realidad en la computadora. Son códigos binarios que luego se traducen para ser visualizados.
El problema lo veo por este lado:
Esos símbolos suelen aparecer solamente si el charset que llega la base es diferente al que espera, cosa que puede pasar si usa UNICODE o LATIN1, dado que la base no espera eso.
Si ese es el problema, y el archivo origen no ha sido editado o modificado luego de realizarse el backup, usualmente es un problema de configuración en el FTP. Y eso no lo vas a corregir simplemente agregando o sacando cosas del archivo.
¿Ese bloque aparece así en pantalla, o es algo que copiaste tu?

Hola.
Ese bloque aparece así en pantalla.
Tal vez sea por esta codificación que tiene el archivo: header('Content-Type: text/html; charset=iso-8859-1');

Iniciado por gnzsoloyo

Ahora bien, yendo al mensaje de error que recibes, es posible que haya otro problema diferente:

Esto otro es puntualmente un problema del backup.
Normalmente un backup no debería generar ese mensaje, si la restauración incluye la creacion misma de la base. Pero es un mensaje habitual cuando lo que está haciendo es una restauración de DATOS sobre una base que ya los tiene.
Es muy común que las tablas tengan campos ID autoincrementales, y que estos sean la PK, especialmente en MyQSL. No es una buena practica, pero es lo que suelen hacer.
El problema es que un campo AI, cuando la tabla ya tiene datos, ya tiene ciertos registros con el valor de ID, y si intentas hacer una restauración de datos desde un archivo, y la base origen de ese archivo contiene todos los ID iniciales, es muy habitual que estés intentando agregar registros a una tabla con un valor de ID que esa base ya tiene en esa tabla.

La importación lo hice en una DB vacía.
Muchas gracias por tu respuesta.

[bohemianproductions]

Hola gnzsoloyo,
Ya se solucionó.
El archivo estaba bien, en la tabla jos_finder_terms de la BD borré las entradas duplicadas y se solucionó el problema.
Ahora ¿por qué había entradas duplicadas? eso si no se...
Le cambié la codificación a UTF-8 y ya no salen esos caracteres extraños.
Muchas gracias.