AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 20.02.2017, 10:10   #21  
Ivanhoe is offline
Ivanhoe
КОРУС Консалтинг
Аватар для Ivanhoe
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
3,548 / 1718 (65) ++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Промежуточное резюме: все упирается в синхронизацию - от 20 минут. Готовых стандартных решений для 2012 нет, в 7ке есть надежда на лучшее.
__________________
Ivanhoe as is..
Старый 20.02.2017, 10:19   #22  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
2,907 / 1538 (57) ++++++++
Регистрация: 12.10.2004
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Промежуточное резюме: все упирается в синхронизацию - от 20 минут. Готовых стандартных решений для 2012 нет, в 7ке есть надежда на лучшее.
Может имеет смысл обсудить подборку нестандартных решений ?
Из моего скромного опыта с 2012-й основное время уходит на запросы к метаданных SQL Server. Думаю рыть надо в сторону их ускорения (запросы к системных вьюхам и.т.п.)
Старый 20.02.2017, 11:01   #23  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2015
 
3,296 / 1320 (51) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Промежуточное резюме: все упирается в синхронизацию - от 20 минут. Готовых стандартных решений для 2012 нет, в 7ке есть надежда на лучшее.
Не только в синхронизацию. В CIL, который надо пересобирать если кастомизации проектами переносить, в AIF/сервисы/SSRS которые будут недоступны пока CIL перестраивается или могут "не подняться" если его целиком не перестроить. Это и AOS-ы живущие на разной бизнес-логике и DDL вроде CREATE INDEX который при работающих пользователях запускается

В принципе, у нас есть клиент 24x7 "от Гуама до Панамы", вот что он делает
a) начинаем заранее drain-ить часть AOS-ов с клиентскими сессиями
b) перенос изменений проектом на выделенный AOS, автоматическая синхронизация
c) CIL
d) перезапуск выделенного AOS-а (сбрасываем метки)
e) перезапуск рабочих AOS-ов по мере освобождения от клиентских сессий с параллельным drain-ом работающих

Формально - у них полного 100% даунтайма нет. По факту - есть ограниченная недоступность на время перестройки CIL (те же 20 минут), вероятность блокировок и "отвала" батчей (особенно это любит делать workflow во время обновления CIL). При инкрементальном обновлении CIL есть ненулевая вероятность отвала SSRS, тогда все бегают с круглыми глазами и все заканчивается часовым простоем с полной компиляцией и CIL. Ну и собственно вопрос - а оно того стоит, и может все-таки выделить 45-60 минут в неделю и сделать все спокойно и без экстрима ?

P.S. В семерке пока что "хуже" (в Вашей постановке задачи) - там простой обязателен и пока что дольше если сравнивать с 2012
__________________
-ТСЯ или -ТЬСЯ ?

Последний раз редактировалось Vadik; 20.02.2017 в 14:15.
За это сообщение автора поблагодарили: EVGL (10).
Старый 20.02.2017, 11:01   #24  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,491 / 4416 (154) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Цитата:
Сообщение от trud Посмотреть сообщение
Документ "Microsoft Dynamics AX 2012 White Paper: Deploying Customizations Across Microsoft Dynamics AX 2012 Environments" описывает довольно экзотические способы снижения downtime "Import a model store with minimal downtime", интересно так кто нибудь делает?
Цитата:
To reduce downtime, we recommend that you import the metadata into a new schema next to the old one, and then switch to the active schema. This methodology lets users continue using the system until the AOS instance needs to be restarted so that the new schema can be applied.
Рассматривали такой вариант на крупном внедрении, к сожалению, он не подошел как раз из-за необходимости останавливать все АОСы одновременно, чтобы переключиться с одной схемы на другую. По описанию логично было бы ожидать, что есть какая-то настройка, указывающая название активной схемы и считываемая АОСом при запуске, однако, это, похоже, не так, и активная схема всегда dbo, а "переключение" заключается в перебивке "временного" названия схемы на dbo, что требует отключения всех АОСов от базы моделей.
Я, может, крамольную вещь скажу, но в моей практике очень часто бывает нужно обновлять рабочее приложение без одновременного перезапуска всех АОСов. Это связано с тем, что обычно АОСы делятся на различные группы по функциональной нагрузке:
  • пользовательские - для подключений виндовым клиентом Аксапты
  • пользовательские - для подключения через Корпоративный портал
  • интеграционные - для хостинга определенных сервисов
  • интеграционные - для хостинга еще каких-либо сервисов
  • пакетные - для, допустим, разноски розницы
  • пакетные - для, допустим, сводного планирования
  • пакетные - для еще каких нужд
При этом в каждой группе обычно используется более-менее явно выраженное подмножество функционала приложения, подчас слабо пересекающееся с другими группами. А еще эти группы характеризуются разной чувствительностью к перезапускам и простоям и разными периодами времени, наиболее подходящими для перезапуска и обслуживания. Пользовательские АОСы обычно можно произвольно перезапускать в нерабочее время (скажем, с 18:00 до 9:00 следующего дня), а пакетные АОСы сводного планирования, напротив, предпочтительнее перезапускать днем. В целом пакетники обычно можно произвольно перезапускать в течение суток, но при условии, что запущенные пакетные задания успели отработать. Прерывать выполняющиеся пакетные задания обычно не очень хорошо, а ждать "парада планет", когда на всех пакетниках завершатся текущие выполняемые задания, можно подчас очень долго. Интеграционные АОСы вообще должны иметь как можно меньшее время простоя, потому что такие простои зачастую приводят к отказу в обслуживании в связанных системах. К примеру, интернет-магазин может замечательно работать автономно от Аксапты, но оплата заказа подарочным сертификатом может завершиться в нем неуспешно из-за невозможности проверить и изменить в online статус подарочного сертификата в Аксапте.
При обновлении рабочего приложения, как правило, переносится функционал, который влияет на одну-две-три группы АОСов с т.з. используемых подмножеств функционала приложения, но очень редко - на все группы сразу. Да, может, это нельзя в каждом случае математически точно обосновать, но из опыта поддержки того или иного приложения обычно это достаточно очевидно. И вот наиболее удобным был бы способ обновления рабочего приложения, который позволял бы разнести во времени перезапуск различных групп АОСов. Скажем, online-интеграциям через WCF-сервисы может быть без разницы, что обновились какие-то формочки для Windows-клиента Аксапты, а АОСам разноски розницы - без разницы, что обновилась логика сводного планирования. Но штатного варианта по сути выполнять две разные версии приложения на разных группах АОСов, к сожалению, нет.
За это сообщение автора поблагодарили: sukhanchik (5), ax_mct (5), trud (2), EVGL (10).
Старый 20.02.2017, 13:43   #25  
Ivanhoe is offline
Ivanhoe
КОРУС Консалтинг
Аватар для Ivanhoe
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
3,548 / 1718 (65) ++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от Vadik Посмотреть сообщение
Не только в синхронизацию. В CIL, который надо пересобирать если кастомизации проектами переносить, в AIF/сервисы/SSRS которые будут недоступны пока CIL перестраивается или могут "не подняться" если его целиком не перестроить. Это и AOS-ы живущие на разной бизнес-логике и DDL вроде CREATE INDEX который при работающих пользователях запускается
Два варианта:
1. отдельная БД с полным CIL, восстановление БД модели на Prod, перезапуск выделенного АОС, на нем же синхронизация, перезапуск АОСов.
2. перенос проектами на выделенный АОС, синхронизация, CIL (инкр / иногда полный), перезапуск по очереди всех АОСов.

Из неудобств - обеспечить не падаемость пакетов - более менее возможно; минимальная синхронизация - вот тут решений особо нет.
__________________
Ivanhoe as is..
Старый 20.02.2017, 22:18   #26  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2015
 
3,296 / 1320 (51) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
отдельная БД с полным CIL, восстановление БД модели на Prod.
Я надеюсь речь все же про импорт modelstore, а не восстановление БД - а то нам и рабочие подключения AOS-ов к model отстреливать придется, и все HA сценарии (database mirroring / availability groups) идут лесом
Так что (1) - не вариант
Цитата:
Из неудобств - обеспечить не падаемость пакетов - более менее возможно
Да, с дополнительными телодвижениями.
Я это все к чему - может, с мегакорпорацией можно как-то договориться об обеспечении полноценного даунтайма, скажем раз в неделю ? Минут в 45 можно уложиться
__________________
-ТСЯ или -ТЬСЯ ?
Старый 20.02.2017, 22:28   #27  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
2,907 / 1538 (57) ++++++++
Регистрация: 12.10.2004
Интересно, а как в других ерп эта проблема решается?
Если тот же сап крутится на sql, то синхронизация займет схожее время. Или нет?
Старый 21.02.2017, 00:52   #28  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,684 / 531 (21) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от Logger Посмотреть сообщение
Интересно, а как в других ерп эта проблема решается?
Если тот же сап крутится на sql, то синхронизация займет схожее время. Или нет?
https://blogs.sap.com/2015/03/11/min...-of-an-update/

In principle two approaches are used:
  • Clone
  • In place
...
The clone approach needs a full copy of the productive system but it is very flexible regarding maintenance activities.
...
nZDT (near Zero Downtime Service)
The nZDT is a service offered by SAP. It is a customer specific procedure that is technically a clone approach.
When using the nZDT service, the maintenance is performed on the clone of the production system. All changes are recorded and transferred to the clone after the maintenance tasks are completed. During the final downtime, only a few activities are executed, including a switch of the production to the new system (clone).
....
ABAP applications, especially the ERP system with DB sizes in range of several terabytes. Therefore the SAP standard tools use the in place approach for ABAP systems in general to minimize the planned downtime. The in place approach uses the DB and needs a minimum of additional Hardware. The downtime minimization capabilities of SUM, e.g. nZDM, use a separate DB schema (shadow).
За это сообщение автора поблагодарили: Logger (3).
Старый 21.02.2017, 03:11   #29  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
1,970 / 874 (33) +++++++
Регистрация: 03.04.2002
Адрес: Australia
Цитата:
Сообщение от Vadik Посмотреть сообщение
Я это все к чему - может, с мегакорпорацией можно как-то договориться об обеспечении полноценного даунтайма, скажем раз в неделю ? Минут в 45 можно уложиться
Можно-то оно можно, если деваться некуда. Только надо понимать что это может стоить мега-корпорации несколько десятков тысяч за каждый простой. Издержки от 50 простоев в год легко могут переваливать за миллион.
Разумо было бы выделять регионы в отдельные инстансы. Тогда ночной простой в Бразилии никак не скажется на работе китайского продразделения.
__________________
Isn't it nice when things just work?
Старый 21.02.2017, 09:42   #30  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2015
 
3,296 / 1320 (51) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от macklakov Посмотреть сообщение
Можно-то оно можно, если деваться некуда. Только надо понимать что это может стоить мега-корпорации несколько десятков тысяч за каждый простой. Издержки от 50 простоев в год легко могут переваливать за миллион.
Разумо было бы выделять регионы в отдельные инстансы. Тогда ночной простой в Бразилии никак не скажется на работе китайского продразделения.
План прекрасный, мне очень нравится. Надо только посчитать стоимость дополнительных лицензий, железа и поддержки множественных инстансов, учесть невозможность (да, по-прежнему) работы в "честном" 24x7 в каждом регионе с 100% доступностью и в общем экономию (или потери) нашей сферической мегакорпорации на этих и прочих мелких нюансах. Но в целом - план прекрасный
__________________
-ТСЯ или -ТЬСЯ ?
Старый 21.02.2017, 10:09   #31  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
1,970 / 874 (33) +++++++
Регистрация: 03.04.2002
Адрес: Australia
Цитата:
Сообщение от Vadik Посмотреть сообщение
учесть невозможность (да, по-прежнему) работы в "честном" 24x7 в каждом регионе с 100% доступностью
Где говорилось что в каждом? 100% 24x7 нужен когда у вас в системе разные регионы, от Бельгии и Бразилии в системе. Это значит что единственный зазор когда пользователей не слишком много, это ночь с субботы на воскресенье. А когда в инстансе лишь несколько близко расположенных стран, то почти все выходные можно что-то делать, ибо количество активных пользователей будет в пределах нескольких десятков.
__________________
Isn't it nice when things just work?
Старый 21.02.2017, 10:31   #32  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2015
 
3,296 / 1320 (51) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от macklakov Посмотреть сообщение
Где говорилось что в каждом?
Не нравится " в каждом" ? Не вопрос - множественные инстансы "честного" 24x7 ни в одном регионе не обеспечивают, так уж система устроена. Так лучше?
Цитата:
100% 24x7 нужен когда у вас в системе разные регионы, от Бельгии и Бразилии в системе
Вы со складом, с которого 24х7 отгрузка идет судя по всему еще не сталкивались
Цитата:
Это значит что единственный зазор когда пользователей не слишком много, это ночь с субботы на воскресенье. А когда в инстансе лишь несколько близко расположенных стран, то почти все выходные можно что-то делать, ибо количество активных пользователей будет в пределах нескольких десятков
Если у мегакорпорации рабочий график 5 дней в неделю, у нее нет проблемы минимизации времени на обслуживание - отмотайте ветку на начало и посмотрите о чем собственно она
__________________
-ТСЯ или -ТЬСЯ ?
Старый 21.02.2017, 10:39   #33  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
1,970 / 874 (33) +++++++
Регистрация: 03.04.2002
Адрес: Australia
Цитата:
Сообщение от Vadik Посмотреть сообщение
Если у мегакорпорации рабочий график 5 дней в неделю, у нее нет проблемы минимизации времени на обслуживание - отмотайте ветку на начало и посмотрите о чем собственно она
Проблема есть. Когда в одном регионе ночь, в другом день, пиковая нагрузка. Когда у одних уже суббота, у других все еще пятница. Когда у других все еще воскресенье, у первых уже понедельник. Поэтому и говорю что единственный более-менее доступный зазор это ночь с субботы на воскресенье. И это даже без круглосуточного склада/производства.

Цитата:
Сообщение от Vadik Посмотреть сообщение
Вы со складом, с которого 24х7 отгрузка идет судя по всему еще не сталкивались
На текущем внедреже именно такой склад. Но ночью в выходные ущерб от простоя минимальный.
__________________
Isn't it nice when things just work?
Старый 21.02.2017, 11:00   #34  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2015
 
3,296 / 1320 (51) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от macklakov Посмотреть сообщение
Проблема есть. Когда в одном регионе ночь, в другом день, пиковая нагрузка. Когда у одних уже суббота, у других все еще пятница. Когда у других все еще воскресенье, у первых уже понедельник. Поэтому и говорю что единственный более-менее доступный зазор это ночь с субботы на воскресенье
Вы меня несколькими сообщениями назад запугали миллионными потерями при 30-45-минутных простоях раз в неделю, а тут раз - и с барского плеча ночь с субботы на воскресенье. В общем, я свое мнение и работающие варианты с их плюсами и минусами уже привел, так что наверное на какое-то время из обсуждения выключусь, тем более что уже перестаю понимать о чем оно
__________________
-ТСЯ или -ТЬСЯ ?

Последний раз редактировалось Vadik; 21.02.2017 в 11:52.
Старый 21.02.2017, 23:08   #35  
Ivanhoe is offline
Ivanhoe
КОРУС Консалтинг
Аватар для Ivanhoe
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
3,548 / 1718 (65) ++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Поменяем мега корпорацию на нормальный интернет-магазин или b2b с кучей проверок при создании заказов. Ну вот не понимают клиенты, почему нужен почти час простоя. Днем офис работает, по ночам склад.
__________________
Ivanhoe as is..
Старый 21.02.2017, 23:14   #36  
Ivanhoe is offline
Ivanhoe
КОРУС Консалтинг
Аватар для Ivanhoe
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
3,548 / 1718 (65) ++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от Vadik Посмотреть сообщение
Я надеюсь речь все же про импорт modelstore, а не восстановление БД - а то нам и рабочие подключения AOS-ов к model отстреливать придется, и все HA сценарии (database mirroring / availability groups) идут лесом
Так что (1) - не вариант
Если не нужна длинная синхронизация, то иногда и просто выключить на пару минут все аосы - вариант. А HA не так уж прям и часто в полный рост настраивают.
__________________
Ivanhoe as is..
Старый 23.02.2017, 22:08   #37  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2015
 
3,296 / 1320 (51) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Поменяем мега корпорацию на нормальный интернет-магазин
Работал я в одном нормальном интернет магазине (>10K заказов в день). Так там не было синхронной интеграции сайта с AX. И у сайта интеграция (асинхронная) строилась так, что не требовала постоянной доступности AX и прочих внутренних приложений. Люди, которые все это строили, знали толк в извращениях интернет-торговле
Цитата:
или b2b с кучей проверок при создании заказов
Ну, B2B тоже в принципе не предполагает наличия людей, нажимающих кнопку на одной стороне и ждущих когда она "отожмется" на другой, так что за нормально сделанный B2B я спокоен
Цитата:
Если не нужна длинная синхронизация
Вот вы привязались к этой синхронизации. Over 90% всех изменений в схеме данных - это добавление полей и создание/изменение индексов. Эти изменения можно делать на выделенном AOS-е без остановки рабочих AOS-ов и при известной доле везения - без "нахлестов" с работающими пользователями. Не нравится / не получается - значит, Вам для полноценного релиза нужен полноценный простой (и совсем не долгий кстати)
Цитата:
А HA не так уж прям и часто в полный рост настраивают
Часто-часто, особенно мегакорпорпорации На самом деле если будете слишком сильно проталкивать схему с восстановлением model из бэкапа, наживете себе кровников в лице БД админов и они же Вас в случае чего сделают крайним - а оно Вам надо ? Импорт modelstore во временную схему делает в итоге то же самое, а переключение схем работает быстрее чем restore database
__________________
-ТСЯ или -ТЬСЯ ?
За это сообщение автора поблагодарили: trud (2), gl00mie (2).
Старый 04.10.2017, 14:23   #38  
Ivanhoe is offline
Ivanhoe
КОРУС Консалтинг
Аватар для Ivanhoe
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
3,548 / 1718 (65) ++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от Vadik Посмотреть сообщение
Вот вы привязались к этой синхронизации. Over 90% всех изменений в схеме данных - это добавление полей и создание/изменение индексов. Эти изменения можно делать на выделенном AOS-е без остановки рабочих AOS-ов и при известной доле везения - без "нахлестов" с работающими пользователями. Не нравится / не получается - значит, Вам для полноценного релиза нужен полноценный простой (и совсем не долгий кстати)
А можно подробнее, как сделать синхронизацию таблицы SalesLine или CustInvoiceTrans на выделенном AOS при работающих пользователях?
__________________
Ivanhoe as is..
Старый 04.10.2017, 15:04   #39  
sukhanchik is offline
sukhanchik
Moderator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,475 / 1573 (57) ++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
А можно подробнее, как сделать синхронизацию таблицы SalesLine или CustInvoiceTrans на выделенном AOS при работающих пользователях?
А сделать это не на выделенном AOS, а в БД, с опцией ONLINE у команды CREATE INDEX? (я говорю конечно же про SQL Server)
Ну т.е. запустили и оно себе работает. Понятное дело - ДБА должны выбрать момент запуска скрипта, но это уже второй вопрос - формально простоя не будет. А АХ уже при обновлении подумает, что этот индекс уже создан.

Глобальная идея состоит в том, чтобы все длительные процедуры, которые выполняются при синхронизации вынести на момент до начала обновления.
Максимальный вариант - это "закат солнца вручную", т.е. выполнение всех процедур, которая делает синхронизация - заранее, до начала обновления. Но обычно хватает "золотой середины", а именно построение долгостроящихся индексов, которые как правило всем известны и для каждой компании можно составить свой список наиболее объемных таблиц
__________________
Возможно сделать все. Вопрос времени

Последний раз редактировалось sukhanchik; 04.10.2017 в 15:08.
Старый 04.10.2017, 15:36   #40  
Ivanhoe is offline
Ivanhoe
КОРУС Консалтинг
Аватар для Ivanhoe
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
3,548 / 1718 (65) ++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Для совсем нагруженных систем других вариантов, кроме синхронизации скриптами прямо на SQL не видно, это понятно.

Но в рамках темы хочется понять, как штатными средствами максимально сократить downtime?
__________________
Ivanhoe as is..
Теги
ax2012, как правильно, обновление, синхронизация

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Перенос пакета и Перекрытие neopl DAX: Функционал 7 15.03.2012 23:12
Финансовые проводки по журналу "Перенос" (AX 2009) MrVlasoff DAX: Функционал 16 22.03.2010 11:32
Перенос конфигурации без данных rwx DAX: Администрирование 9 01.10.2009 10:15
Перенос переменной в конфигураторе продукции Serg DAX: Функционал 0 09.12.2005 13:43
Перенос номенклатуры со склада на склад efim DAX: Функционал 4 04.04.2003 13:56
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 07:50.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.