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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 13.06.2012, 16:30   #41  
ice is offline
ice
Участник
Аватар для ice
Лучший по профессии 2014
 
1,732 / 406 (17) +++++++
Регистрация: 23.03.2006
Цитата:
Сообщение от kashperuk Посмотреть сообщение
Дык не идут к нам...
А те, кто идут, не справляются многие с техническими задачами на интервью.

Более того, ERP программирование - это чуть специфическая область, а нанимаем мы обычно "for Micorosft", то есть человек этот должен иметь потенциал для продолжения работы в Майкрософт в другой команде, к примеру.
т.е нанятые люди разрабатывать erp должны одинаково уметь писать драйвера, к клепать игрушки для иксбокс

Последний раз редактировалось ice; 13.06.2012 в 16:32.
Старый 13.06.2012, 17:39   #42  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Цитата:
Сообщение от ice Посмотреть сообщение
т.е нанятые люди разрабатывать erp должны одинаково уметь писать драйвера, к клепать игрушки для иксбокс
Предыдущий опыт не так важен, как возможность достичь успеха в любой из вышеперечисленных областей.
То есть не обязательно это УЖЕ уметь, но надо быть достаточно сообразительным, чтобы научиться.
Старый 13.06.2012, 20:53   #43  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5798 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от fed Посмотреть сообщение
С точки зрения производительности, выгодно указывать список полей если у вас в таблице много полей (то есть эдак штучек 50). Но мы ведь не делаем таких плохо нормализованных таблиц, правда ведь?
Любые шапки/строки журналов/заказов/документов (которые надо иметь возможность перепечатывать постфактум в исходном виде несмотря на изменения в справочниках), сами справочники (клиенты, поставщики, номенклатура, сотрудники, ОСы, etc) обычно даже в стандартном приложении содержат число полей, близкое или намного превышающее указанный предел, а уж с учетом кастомизаций - и подавно.
Цитата:
Сообщение от fed Посмотреть сообщение
Как мы все знаем, в реальной жизни, доработки нужны "еще позавчера", времени их продумывать и тестировать ни у кого нету и шансы что после такой оптимизации какая-то логика сильно поломается - очень велики.
Это точно: как только возникает необходимость передать выбранный табличный буфер в другой метод или дернуть метод самой таблицы, лучше сразу отказываться от выбора подмножества полей.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Бага в Query update(true) Alexius DAX: Программирование 5 14.09.2011 14:09
Не срабатывает skipDatabaseLog(true) jaran DAX: Программирование 14 09.04.2011 13:22
visible(true) и курсор mvf DAX: Программирование 6 20.07.2005 10:09
recordLevelSecurity(true) sassas DAX: Программирование 12 23.12.2004 16:44

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

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

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