Importar artículos

Xarlie

Super Moderador
Miembro del equipo
No es un script, es una instrucción.
Esa instrucción se usa en Magento para pedir al servidor Apache que no corte la ejecución del script pasados x segundos. Por defecto hay siempre una duración, para evitar que se te queden colgados ciertos scripts y puedan hacerte caer el servidor

Pero desde PHP se puede evitar ese tiempo, "sobreescribiendo" esa variable que se define en el PHP.INI de tu configuración.
Lo que pasa que en ocasiones los administradores de máquinas (sobre todo compartidas) evitan que ciertas variables se puedan sobreescribir para evitar que haya usuarios que "chupen" todos los recursos de una máquina donde puede hacer ¿2000? webs o más.

Por otra parte, estaba pensando ¿es al importar un fichero? A ver si el fichero es demasiado grande y supera la restricción de tamaño de tu servidor para recibir archivos mediante POST/GET...

¿Qué tamaño tiene el csv? ¿Que tamaño límite tiene tu servidor?
 

entolium

Nuevo usuario
De lo que se entera uno :jeje:

El archivo pesa unos 4 Mb, pero con archivos mucho más pequeños también me ocurre (por ejemplo un archivo con 925 registros con el campo SKU y small_image). Siempre se corta más o menos en el registro 170.

Hoy he borrado todos los productos desde el admin, y me ha ocurrido lo mismo. He tenido que seleccionar todo y borrar unas cuatro o cinco veces porque saltaba el error de tiempo de espera agotado (30 seg) y sólo se borraban unos 170...180 registros en cada borrado.
 

Xarlie

Super Moderador
Miembro del equipo
Si el error es el de 30 segundos entonces es por la limitación del apache.

El set_time_limit no te está funcionando y te va a dar bastante problemas... con connect, con subir archivos grandes...

Imagino que no te funciona por el safe mode... prueba a quitar el safe mode de tu servidor
 

Xarlie

Super Moderador
Miembro del equipo
entolium haz esta prueba:

- Te abres el fichero index.php (el fichero del raíz de tu web)
- Añades esta línea justo al comienzo del código (justo encima del if que comprueba la versión de php).

PHP:
set_time_limit(0);
- Pruebas de nuevo y me cuentas :)
 

Antonio

Nuevo usuario
Al hilo de este post quiero dejar un comentario a OsDave, Xarlie, entolium, tamagochi, y demas almas de magento:

Hasta la version 1.1.6 en la importación de nuestros productos (en formatio excel xml) habia un primer campo llamado "store" en el que poniamos el nombre o código que le habiamos dado a la tienda, en este caso siempre poniamos "consumibles_es".

Después de la actualización desastrosa de la 1.1.7 y de la siguiente 1.1.8 hemos comprobado lo siguiente:

Cuando hemos querido importar de la manera que explicaba, poniendo en store "consumibles_es", lo hace bien e incluye los productos tanto en zona publica como en la privada. Pero... ahora viene lo bueno, si quieres editar un producto desde la parte privada de forma manual por una extraña razón no te lo actualiza en la parte publica.
Sí lo hace (editar y actualizar bien) si ponemos "admin" en el campo store.

En Magento tenemos (como poco) 2 tiendas. La tienda "admin" (tienda base del sistema magento) y la tienda "consumibles_es". El caso es que al importar desde el XML para la tienda "consumibles_es" se crean registros para ambas tiendas y no solo para la tienda que se defina en el xml, se duplica la información, lo cual no era problema hasta la actualización 1.1.8.

En anteriores versiones, si la importación solo se hacía a la tienda "admin" los productos no aparecían en la parte pública y por eso había que importar a la tienda creada (consumibles_es en nuestro caso) para poder trabajar normalmente. Esto era un bug conocido.

Lo que pasa después de la actualización es que se importa a la tienda "consumibles_es" pero si hay registros para las 2 tiendas aparece primero la información de admin que de consumibles_es en la parte publica. y en la parte privada pasa lo contrario. Editas en la tienda consumibles_es pero lo que se ve en la parte publica es lo que hay en la tienda admin.

La solución pasa por exportar a la tienda "admin" en lugar de a la tienda "consumibles_es" en nuestro caso.

Bien despues de todo este rollo:sleep: hay algun alma que no le pase lo que a nosotros o que le haya pasado y tenga una solución.
 

Xarlie

Super Moderador
Miembro del equipo
Uhmmmm... ahora si que estoy perdido... si no te da el error es porque puede coger todo el archivo, pero por alguna razón no puede guardar todo... no se me ocurre nada ahora mismo :(
 

jogide

Nuevo usuario
Al hilo de este post quiero dejar un comentario a OsDave, Xarlie, entolium, tamagochi, y demas almas de magento:

Hasta la version 1.1.6 en la importación de nuestros productos (en formatio excel xml) habia un primer campo llamado "store" en el que poniamos el nombre o código que le habiamos dado a la tienda, en este caso siempre poniamos "consumibles_es".

Después de la actualización desastrosa de la 1.1.7 y de la siguiente 1.1.8 hemos comprobado lo siguiente:

Cuando hemos querido importar de la manera que explicaba, poniendo en store "consumibles_es", lo hace bien e incluye los productos tanto en zona publica como en la privada. Pero... ahora viene lo bueno, si quieres editar un producto desde la parte privada de forma manual por una extraña razón no te lo actualiza en la parte publica.
Sí lo hace (editar y actualizar bien) si ponemos "admin" en el campo store.

En Magento tenemos (como poco) 2 tiendas. La tienda "admin" (tienda base del sistema magento) y la tienda "consumibles_es". El caso es que al importar desde el XML para la tienda "consumibles_es" se crean registros para ambas tiendas y no solo para la tienda que se defina en el xml, se duplica la información, lo cual no era problema hasta la actualización 1.1.8.

En anteriores versiones, si la importación solo se hacía a la tienda "admin" los productos no aparecían en la parte pública y por eso había que importar a la tienda creada (consumibles_es en nuestro caso) para poder trabajar normalmente. Esto era un bug conocido.

Lo que pasa después de la actualización es que se importa a la tienda "consumibles_es" pero si hay registros para las 2 tiendas aparece primero la información de admin que de consumibles_es en la parte publica. y en la parte privada pasa lo contrario. Editas en la tienda consumibles_es pero lo que se ve en la parte publica es lo que hay en la tienda admin.

La solución pasa por exportar a la tienda "admin" en lugar de a la tienda "consumibles_es" en nuestro caso.

Bien despues de todo este rollo:sleep: hay algun alma que no le pase lo que a nosotros o que le haya pasado y tenga una solución.
Recupero el hilo porque a mi me da que mi problema viene de algo parecido. Tengo muchas incidencias con las bases de datos, hi ha sido después de importar artículos con el import con la actualización 1.1.8.


Referente a el error haciendo CHECK TABLE:
(antes de nada, perdón por el cambio de idioma... se entiende bien, pero dice algo así como

Problema con los indices de la tabla 'blablalba'.
Las claves PRIMARY y INDEX no se puedes al mismo tiempo para la columna 'store_id'
Se ha creado más de una clave INDEX para la columna 'store_id'



"
Problemes amb els index de la taula `catalogindex_eav`
Les claus PRIMARY i INDEX no es poden establir alhora per a la columna `store_id`
Problemes amb els index de la taula `catalogindex_price`
S'ha creat més d'una clau INDEX per a la columna `store_id`
Problemes amb els index de la taula `cataloginventory_stock_item`
Les claus UNIQUE i INDEX no es poden establir alhora per a la columna `product_id`
Problemes amb els index de la taula `catalog_category_product`
Les claus UNIQUE i INDEX no es poden establir alhora per a la columna `category_id`
Problemes amb els index de la taula `catalog_category_product_index`
Les claus UNIQUE i INDEX no es poden establir alhora per a la columna `category_id`
Problemes amb els index de la taula `catalog_compare_item`
S'ha creat més d'una clau INDEX per a la columna `customer_id`
Problemes amb els index de la taula `catalog_product_enabled_index`
Les claus UNIQUE i INDEX no es poden establir alhora per a la columna `product_id`
Problemes amb els index de la taula `catalog_product_entity_datetime`
S'ha creat més d'una clau INDEX per a la columna `entity_id`
Problemes amb els index de la taula `catalog_product_entity_decimal`
S'ha creat més d'una clau INDEX per a la columna `entity_id`
Problemes amb els index de la taula `catalog_product_entity_int`
S'ha creat més d'una clau INDEX per a la columna `entity_id`
Problemes amb els index de la taula `catalog_product_entity_text`
S'ha creat més d'una clau INDEX per a la columna `entity_id`
Problemes amb els index de la taula `catalog_product_entity_varchar`
S'ha creat més d'una clau INDEX per a la columna `entity_id`
Problemes amb els index de la taula `core_translate`
Les claus UNIQUE i INDEX no es poden establir alhora per a la columna `store_id`
Problemes amb els index de la taula `core_url_rewrite`
Les claus UNIQUE i INDEX no es poden establir alhora per a la columna `store_id`
S'ha creat més d'una clau INDEX per a la columna `store_id`
S'ha creat més d'una clau UNIQUE per a la columna `store_id`
Problemes amb els index de la taula `eav_attribute_group`
Les claus UNIQUE i INDEX no es poden establir alhora per a la columna `attribute_set_id`
Problemes amb els index de la taula `eav_attribute_set`
Les claus UNIQUE i INDEX no es poden establir alhora per a la columna `entity_type_id`
Problemes amb els index de la taula `eav_entity_attribute`
Les claus UNIQUE i INDEX no es poden establir alhora per a la columna `attribute_set_id`
Problemes amb els index de la taula `eav_entity_datetime`
S'ha creat més d'una clau INDEX per a la columna `entity_type_id`
S'ha creat més d'una clau INDEX per a la columna `attribute_id`
Problemes amb els index de la taula `eav_entity_decimal`
S'ha creat més d'una clau INDEX per a la columna `entity_type_id`
S'ha creat més d'una clau INDEX per a la columna `attribute_id`
Problemes amb els index de la taula `eav_entity_int`
S'ha creat més d'una clau INDEX per a la columna `entity_type_id`
S'ha creat més d'una clau INDEX per a la columna `attribute_id`
Problemes amb els index de la taula `eav_entity_varchar`
S'ha creat més d'una clau INDEX per a la columna `entity_type_id`
S'ha creat més d'una clau INDEX per a la columna `attribute_id`
Problemes amb els index de la taula `tax_calculation`
S'ha creat més d'una clau INDEX per a la columna `tax_calculation_rate_id`
Problemes amb els index de la taula `tax_calculation_rate_title`
S'ha creat més d'una clau INDEX per a la columna `tax_calculation_rate_id` "

Millones de gracias :guiño:
He estado indagando por el mysql y creo que ralentiza la página por este desbarajuste de tablas que no entiendo.
 
Última edición por un moderador:

jogide

Nuevo usuario
No es desbarajuste de tablas, las tablas están relacionadas entre sí y por eso te devuelve mensajes de ese tipo.
O sea, no es problema ? En el foro general habia otro afectado y lo planteaba como tal.

Entonces esto no tiene nada que ver con mi lentitud...

Vaya, por un lado me alegraba si habia encontrado mi fallo... :enfadado:
 

Xarlie

Super Moderador
Miembro del equipo
En principio no te tendría que dar ningún error, eso es cierto. Te tendría que decir que la tabla ha sido optimizada o que ya estaba optimizada.
Pero yo tengo las mismas tablas con varios índices primarios, tal y como te dice los errores y no me da problemas...
Las tablas son en innoDB o MyIsam? No se... podría ser el problema...

Haz una prueba, bajate los datos de ejemplo. Te creas una nueva base de datos e importas a esta bdd los datos de ejemplo y después intentas optimizar. Si te devuelve los mismos errores es posible que haya errores con tu instalación de MySQL o que sea por la versión.

Yo trabajo en versiones de MySQL 5.+ ¿tienes una versión 4?
 

jogide

Nuevo usuario
Ok, hare estas pruebas.

Versión del servidor: 5.0.51a-3-log
Versión del protocolo: 10
Servidor: Localhost via UNIX socket
Juegos de caracteres de MySQL: UTF-8 Unicode (utf8)
Cotejamiento de las conexiones MySQL:

Me da la opción de reparar las tablas, yo solo he optimizado. Le pego castaña ?

Otro gaje de mi proveedor és que solo dispongo de sitio para una Bdd. Buscaré algún sitio para probar.

Bufff, esto és dificil.
 

Xarlie

Super Moderador
Miembro del equipo
Sí, prueba también a reparar... toda opción es poca.
También puedes mirar en la zona de procesos (no se si tendrás permisos para ver esa zona) y allí te muestra los tiempos de las consultas y las slow queries.
 

jogide

Nuevo usuario
Nada, no me deja reparar tablas:

The storage engine for the table doesn't support r...

y puede ser que quiera decir:

The storage engine for the table doesn't support check (sacado de google)

Creo que voy a buscar algún especialista en bdd...

edito: toqueteando el mysql, he encontrado esto:

slow_queries : 1
 
Última edición:

Xarlie

Super Moderador
Miembro del equipo
Puede ser que el usuario con el que manejas las bases de datos no tenga la opción de optimizar tablas. Eso depende de los privilegios con los que tu usuario cuente.
 

jogide

Nuevo usuario
Nada Xarlie, olvidate del tema.

Lo dicho, me buscaré a alguien entendido en Bdd.

A parte, comentar que creo que el problema viene de servidor, ayer mejoró sustancialmente por la mañana, sin haber tocado nada, por la tarde funcionaba bien, y hoy volvemos a arrastrarnos por la web.

Y los del hosting me dicen que ellos no tocan nada :enfadado:

Gracias igualmente.
 
Arriba