Форум

Это, конечно, замечательно. Вы хоть документацию по Битриксу читали вообще? С классами CSaleOrder и CSaleBasket разобраться пытались? Все, что Вы сделали этим кодом - изменили ВЫВОД на СТРАНИЦЕ одного заказа. Прежде чем браться за такие задачки, разберитесь, как вообще работает компонент заказа, логику его изучите, API интернет-магазина.

[QUOTE]Сергей Куликов пишет:
Далее создал новый заказ и у меня старый разбитый заказ вновь объеденился [/QUOTE]
Значит, не присвоили. Код свой покажите.

[QUOTE]invicta пишет:
они же должны оставаться по-любому закрепленными за зарегистрированным пользователем, если он выбрал, но не оформил товар... [/QUOTE]
речь шла о ситуации, когда человек накидал в корзину товаров, заказ не оформлял и не авторизовался.

[QUOTE]Николай Чирясов пишет:
я думаю - глюк
т.к. наблюдался изначально и не на одном магазине[/QUOTE]
А мысли, что так правильно, Вы не допускаете?
[QUOTE]invicta пишет:
так это глюк программы и надо что-то подгружать или менять?[/QUOTE]
Такая проблема решается просто - вешаете на событие OnAfterUserLogout функцию, удаляющую все куки битрикса с машины. Два недостатка:
1. При закрытии браузера ничего не сотрется.
2. Неоформленные товары в корзине исчезнут.

[QUOTE]Семен Пупков пишет:
Странно, документации вроде это не описано. [/QUOTE]
Ну, если ее по диагонали читать, то да, не описано.

Возможно. Вешаете на cron импорт.

Подробнее. Чей $arResult надо сохранить? Если "компонента_2", что мешает возвращать его ($arResult) в конце компонента?

[QUOTE]Alex Kharitonov пишет:
Хмм. Старый движок был самописный и работал раз в 20 быстрее битрикса при схожем функционале (правда там все было оптимизировано под конкретные задачи без универсальных решений). [/QUOTE]
Универсализм не дается бесплатно. Я , кста писал, почему не рекомендуют юзать чистый SQL.
[QUOTE]Alex Kharitonov пишет:
А как вы решаете вопрос с обновлениями версий битрикса при использовании чистого SQL? Он у вас не связан с другими частями?[/QUOTE]
Элементарно. То, что может быть затерто, проверяю после обновления. Но в ядро не лезу.[QUOTE]Alex Kharitonov пишет:
Как это проверить, нигде не нашел?[/QUOTE]
Зайдите в свойства инфоблока. Если написано, что данные хранятся в общей таблице - это 1.0 (по умолчанию). Конвертация инфоблока с ~ 40 тыс. записей у меня заняла час-полтора. Все это время доступ к сайту посетителей, мягко говоря, нежелателен.
[QUOTE]Alex Kharitonov пишет:
В примерах работ я видел сайты Эльдорадо, Банки.ру, Гдеэтотдом, там ведь тоже по большие базы и много выборок из них. Любопытно, как там реализованы эти механизмы? [/QUOTE]
Как мне в свое время ответила ТП - под крупные проекты всегда идет заточка ;)
[QUOTE]Alex Kharitonov пишет:
Кстати, заметил, что стандартные компоненты типа фотогалереи, форум и др, работают сравнительно быстро. Возможно, разработчики не учили особенности битрикса при создании компонентов.

Где можно об этом почитать? [/QUOTE]
Очень вероятно. Как вариант - неоптимальный кеш.[QUOTE]Alex Kharitonov пишет:
Еще вопрос, насколько принципиально выделять рабочий функционал в компонент или использовать прямо в файле: sitename.ru/service/index.php [/QUOTE]
Все, что нуждается в настройках и кешировании, должно быть в компонентах. Точка.
Любые другие варианты - чистой воды мазохизм, с этим к психиатру.
[QUOTE]Alex Kharitonov пишет:
Интересно, отказ от mySQL в пользу Oracle сильно увеличит производительность? [/QUOTE]
Нет. Сильно увеличит производительность тюнинг БД.

Весь код приведите.

[QUOTE]Sergey Leshchenko пишет:
Ну, смотрите, кеш в среднем дает экономии в 40-50% времени генерации компонента. [/QUOTE]
Не поделитесь, откуда такие данные? У меня как-то все от 90% до 99% получается. Может, я их готовлю неправильно?

[QUOTE]Sergey Leshchenko пишет:
И вообще загляните в bitrix:menu.sections, если вы этого не делали, много радостного там увидите. [/QUOTE]
И заглядывал, и переписывал для своих нужд. Я понять не могу - откуда будут вызовы _ext.php, если меню УЖЕ закешировано?