Алексей, удалось решить проблему? У меня вдруг ни с того, ни с сего возникла та же ситуация. Все работало, а потом вдруг перестало работать с такой ошибкой.
19.08.2010 17:46:11
Подключил собственный php.ini на сервере, увеличил upload_max_filesize и post_max_size до 64 мегабайт. Исчезла ошибка 2 (превышен максимальный размер файла), но появилась 3 (Файл не отправлен).
Отключил mbstring - исчезла и третья ошибка. Насколько мне известно, Битрикс использует mbstring в модуле поиска. Боюсь, как бы опять проблемы не начались. |
|
|
19.08.2010 17:31:59
Здравствуйте. Собственно, вопрос в теме озвучен. Поясню детальнее: есть каталог товаров и связанный с ним "пакет предложений". Если из основного каталога удалить выборочные папки, то в пакете предложений остаются записи без связей. Как их можно удалить, не затронув правильные записи? Писать собственный скрипт с выборкой элементов или есть более быстрый способ?
|
|
|
19.08.2010 16:39:26
Здравствуйте.
Хочу обратить внимание на последнее обновление, в котором приехали исправления обмена с 1С. После них у нас на сервере стали твориться чудеса обмена. Ошибки сыпятся, как снег в феврале. (Конечно может это у нас руки кривые, что не исключаю). Оговорюсь сразу — до этого каталог в 6000 наименований + 10000 предложений выгружался вполне успешно, хотя и разбиваем по частям для снижения нагрузки. Описываю по-порядку происходящее. 1. При импорте встретилась валюта цены содержащая не латинские буквы. Цена была импортирована с валютой RUB. Ну, нам-то RUB особо погоды не делает. Поэтому попробуем назвать в справочнике "UAH - гривна" и проверим, чего будет. 2. Затем практически сразу же сервер вдруг стал выдавать: "Неверный тип файла, либо превышен максимальный размер файла!Неверный тип файла, либо превышен максимальный размер файла!" 3. Следом за этой ошибка: "Произошла ошибка на стороне сервера. Файл не отправлен (C:\Documents and Settings\Администратор\Local Settings\Temp\v8_2_ae1.zip.01).". Боролись играя с правами доступа на папки. И, что удивительно, при правах доступа "777" напрочь отказывалось работать. А при 755 — стало нормально загружать файлы. Сжатие zip рояли не сыграло, поэтому после экспериментов включили его обратно (а зря). 4. Вроде бы только утрясли все, как на следующий день выпало: "Произошла ошибка на стороне сервера. Получен неизвестный статус импорта. ... куча html ... куча html Table 'b_xml_tree' already exists" — похоже Битриксу не удалось удалить таблицу b_xml_tree. Проверили БД - все нормально, сбоев нет. Выключил Zip-сжатие (хотя не логично) и ошибка исчезла. Теперь, собственно вопросы: 1. Почему Zip-сжатие криво работает? Как его правильно настроить? 2. Кто-то пользовался hostpro.ua (виртуальный хостинг)? Может нужно какие-то особые настройки php сделать, чтобы избавиться от этих проблем? 3. Пока писал письмо, проверили с валютами - действительно помогло переименование. |
|
|
15.08.2010 13:34:08
Был вопрос:
Нашел, где оно прячется. В свойствах заказа. |
|
|
14.08.2010 12:53:44
Кхм. Теперь нашел. По-умолчанию было скрыто. Ну зачем же оно скрыто?!? Столько проблем исчезло бы.
Я имею ввиду, когда делается сжатие базы данных средствами 1С и открытие на другом компьютере (когда настраивали и дорабатывали Битрикс, работали вдвоём). Насколько мы заметили, что если выгрузка произошла с другого компьютера - XML_ID менялся. Про РИБ не вкурсе, что это? |
|||||
|
13.08.2010 11:23:12
Методом опытного научного тыка удалось выяснить, что новые идентификаторы появляются в основном после архивации / развертывания базы, при экспорте с разных компьютеров (тестовый и рабочий). Иногда в непонятных ситуациях. Возможно, что и при настройке новых обменов, как написал Роман.
В результате мы нашли, где в 1С это делается (генерация случайного ID) и просто прописали фиксированный XML_ID. А то надоело это безобразие. |
|
|
12.08.2010 04:08:35
Выгружаю каталог. В XML в самом верху есть ID, на который потом завязывается вся процедура обмена. Выглядит он так:
Вопрос: от чего зависит этот идентификатор "Ид" и почему он постоянно меняется, ввергая меня в пучину нервных страданий? Спасибо всем, кто откликнется. |
|||
|
06.08.2010 14:40:01
Дмитрий Козлов, спасибо, я уже разобрался
|
|
|
06.08.2010 13:57:52
Используется bitrix:catalog, конкретнее шаблон catalog.element.
Выборка сделана с параметрами, указанными ниже. Вопрос в следующем: как сделать, чтобы пользователи, состоящие в определённых группах, видели только свои типы цен? В панели управления (Рабочий стол / Магазин / Торговый каталог / Типы цен) указал ограниченные привилегии: - Группы пользователей, имеющие права на просмотр этого типа цен - Группы пользователей, имеющие права на покупку по этому типу цен Но не смотря на это, пользователь состоящий в группе "Зарегистрированные пользователи" видит все цены, выведенные в шаблоне catalog.element. Я вижу решение методом "костылей" в том, чтобы до подключения компонента "bitrix:catalog" проверить, в какой группе состоит пользователь, и в зависимости от результата указывать параметр "PRICE_CODE". Но будет ли при этом правильно работать заказ товара? Тем более в интеграции с 1С. Вот код подключения каталога:
P.S.: Смотрите |
|||
|
03.08.2010 10:03:43
Я даже устанавливал специально повышенный приоритет всем процессам, связанным с выгрузкой (httpd, mysql, 1c, ...). Дело не в них. Просто кодеры из 1С-Битрикс перемудрили с механизмами и где-то идёт сбой, из-за чего таблица b_xml_tree раз за разом обнуляется и процесс входит в вечный цикл. Перенёс сейчас всё это дело на другой компьютер, чтобы частями отлаживать процесс выгрузки. Вероятнее всего, что нужно периодическую выгрузку делать не полную, а также - частями (по группам товаров), чтобы снизить нагрузку на сервер и уменьшить вероятность глюков.
Дополнительно осложняет работу тот факт, что "Файлов: 22 413; папок: 9 542" — это не шутки. Полная распаковка системы занимает сама по себе до 4х часов времени. Плюс обнаружилось, что в полном бекапе *.tar.gz ещё и не все файлы оказались. |
|
|
01.08.2010 23:10:36
22:00. Синхронизация так и не была завершена. Ну а мы продолжаем наши изыскания.
Представляем широкому вниманию таблицу b_xml_tree. Структура таблицы: ID int(11) PARENT_ID int(11) LEFT_MARGIN int(11) RIGHT_MARGIN int(11) DEPTH_LEVEL int(11) NAME varchar(255) VALUE text ATTRIBUTES text Пример содержания: ID PARENT_ID LEFT_MARGIN RIGHT_MARGIN DEPTH_LEVEL NAME VALUE ATTRIBUTES 136807 136803 273607 273608 6 Валюта грн NULL 136806 136803 273605 273606 6 ЦенаЗаЕдиницу 1,47 NULL 136805 136803 273603 273604 6 ИдТипаЦены a9d725... NULL 136804 136803 273601 273602 6 Представление 1,47 грн. за шт NULL И так - под два миллиона записей. Два миллиона (!) раз повторять тип переменной, записывая его кириллическими (!) символами в поле типа varchar с резервом в 255 символов! Где бы найти хорошую метлу, чтобы изгнать беса, который придумал ЭТО?!? Как это можно допускать вообще в программировании? И где? В компании 1С! (дальше отборный мат) Нужно занести этот метод в учебники, как пример самого нереально-извращённого способа решения поставленной задачи обмена. P.S.: С 6:00 до 22:00 за сегодня, |
|
|
01.08.2010 21:35:57
Попытка номер два.
Выключаю проактивную защиту. На локальном компе выключаю интернет, файервол, весь лишний софт. Настраиваю MySQL согласно инструкциям из справки и из форумов по оптимизации MySQL. Перевожу все таблицы в InnoDB. Включаю параметр define("MYSQL_TABLE_TYPE", "InnoDB"). my.cnf:
Устанавливаю ZendOptimizer. Перезапускаю сервер. Стартую выгрузку в 15:00. 1С сообщает: - Выгружено товаров: 6153 - Выгружено картинок: 2332 - Выгружено файлов: 51 - Выгружено предложений: 12891 На "Временные таблицы созданы" как всегда уходит в глубокий штопор. В процессе наблюдаю за таблицей b_xml_tree. Она бесконечно-изменяется, каждую секунду прибавляется по 1000-2000 записей. Идентификатор ID растёт, вырастает до значений (внимание) выше 1700000 — почти два миллиона записей Затем обнуляется и процесс повторяется. За несколько часов выгружается "Основной каталог товаров" (не знаю, полностью ли). "Пакет предложений" так и не меняется. Сейчас 20:20. Выгрузка всё продолжается и конца не видно. b_xml_tree выростает / обнуляется / выростает / обнуляется и так бесконечно. Это какой-то идиотизм. У меня нет ни одного разумного довода в пользу системы, которая на 12891 + 6153 записей плодит таблицу с миллионными количествами строк и при этом ещё и неоднократно. Объясните мне: это полный коллапс мышления программистов, создававших выгрузку или всё-таки что-то где-то волшебным образом нужно настроить? Пошел шестой час выгрузки шести тысяч товаров! Всё больше склоняюсь к мысли, что нужно написать собственный механизм выгрузки, скооперировавшись с 1с-никами из офиса. Скорость работы MySQL: 1000-2000 запросов в секунду. На каждый товар, допустим, выделяется по 3 строки в разных таблицах. Плюс у каждого товара есть как минимум один дубликат (ну не бред ли?) — это его "пакет предложений". Вот алгоритм, рождённый "от балды": 1. 1С соединяется с сервером и передаёт полную выгрузку товаров в виде чистых SQL-запросов (а не хронического дибилизма в XML). Также передаёт простенький конфиг, в котором описана структура (вот для этого, блин, существует XML) переданных данных. 2. Сервер Битрикс сравнивает структуру, переданную от 1С со своей структурой объектов - и если не совпадает, сообщает об этом и прерывает синхронизацию, либо добавляет / игнорирует недостающие поля. 3. Сервер читает конфиг, создаёт временные таблицы согласно переданной структуре (с точными характеристиками полей). 4. Затем импортирует SQL-файл. 12891 + 6153 = 19 044 / 1000 запросов в секунду = пару минут времени максимум даже на слабых машинах. 5. Пробегаем SELECT-ом по временной таблице, выбираем связку товаров id=>last_upd_time. То же по реальным товарам. Определяем те, которые не сходятся (не существуют на сайте, либо обновлены). Тут у нас уходит, допустим, до пяти минут. 6. Добавляем новые, обновляем старые (если это выгрузка на пустую базу, то это ещё пару минут). На лету перебиваем ссылки на вложения / графику, которая была передана с 1С. 7. То же проделываем с дополнительными характеристиками "пакета предложений". Плюс 5-10 минут предел. 8. Синхронизируем заказы, конец. Если пройдёт 30 минут - я буду удивлён. Одно но: нужно перелопатить всю структуру данных Битрикс, чтобы понять где именно, как и чем связаны товары из b_iblock_element с другими таблицами. А это могут знать досконально только разработчики Битрикс. Если знают, конечно... |
|||
|