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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 09.07.2008, 16:01   #1  
Arahnid is offline
Arahnid
Участник
 
880 / 60 (4) ++++
Регистрация: 09.08.2005
Адрес: Moscow
Цитата:
Сообщение от egorych Посмотреть сообщение
SYSDATABASELOG не заполняете? Или историю по этим табличкам не ведете ?
мы не ведем.

Товарищи, которые не рекомендовали так делать, объясните - почему вы все же не рекомендуете так делать?
Пока не увидела ни одной веской причины, что у меня не будет работать.
Старый 09.07.2008, 16:18   #2  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5798 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от Arahnid Посмотреть сообщение
объясните - почему вы все же не рекомендуете так делать?
В условиях работоспособности вашего варианта решения слишком много "если":
  • если не вести логирование И
  • если правила трансляции останутся счет - в счет И
  • если не понадобится навесить доп.логику на создание проводок в LedgerTrans И
  • если ...
плюс, оно "дороже" в плане сопровождения - тому, кто будет поддерживать такое решение, надо будет:
  • уметь писать хранимки на T-SQL или PL/SQL;
  • иметь соотв. доступ к базам (разработческой, тестовой, рабочей);
  • не забывать переносить отдельно еще и эти хранимки при обновлениях кода;
  • не забыть перенести их на новую базу, если понадобится тиражировать ваше решение;
  • etc...
А в остальном, никто, конечно, не утверждает, что ваше решение не будет работать. Работать оно будет - вопрос лишь, при каких условиях и ценой каких затрат...

PS. Вот еще, вспомнились Безболезненные функциональные спецификации Джоэла Спольски:
Цитата:
Хуже всего, что программист, который потратил 2 недели на написание определенного кода, привязывается к нему душой, независимо от того, насколько тот неправильный. Неважно, что скажут начальник и заказчики Быстряковой. Они не убедят ее выбросить прекрасный код конвертера, даже если он имеет не самую лучшую архитектуру. В результате конечный продукт имеет тенденцию становиться компромиссом между изначально неправильной разработкой и идеальной разработкой. Это было «лучшей разработкой, которую мы могли получить, учитывая то, что мы уже написали весь этот код, и мы просто не хотим его выбрасывать». Это звучит не так хорошо, как «самая лучшая разработка, которую мы могли получить. Точка».
Так что не торопитесь реализовывать ваше решение, подумайте...

Последний раз редактировалось gl00mie; 09.07.2008 в 16:27. Причина: дополнение
За это сообщение автора поблагодарили: oip (2).
Теги
recid, systemsequences, t-sql, интеграция

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
if (record) vs if (record.RecId) kashperuk DAX: Программирование 18 27.11.2008 18:53
поля, содержащие RecId somebody DAX: Программирование 15 16.05.2008 17:50
Что лучше select RecId или select TableId Logger DAX: Программирование 9 02.06.2007 15:13
aEremenko: Дефрагментация RecID Blog bot DAX Blogs 2 06.03.2007 22:25
Два RecId у одной записи таблицы sparur DAX: Программирование 33 18.12.2006 15:56
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 04:38.