технические аспекты (максимально сжато, но достаточно подробно и из личного опыта, всё ИМХО):

ИСПОЛЬЗУЕМЫЕ СУБД:
Navision Server
Navision Server - примитивный безSQL серверок, просто подающий записи на клиента. Ни с кем другим не совместим и не похож.
До 140Гб данных, Не более 1Гб ОЗУ, 1CPU. Поддерживает только одну (!) базу.
Для использования 2-х баз нужно ставить 2 копии сервера :).
Для работы в однопользовательском режиме сервер вообще не нужен и Navision работает с файлом данных подобно ACCESS с *.MDB,
но в отличие от ACCESS второй пользователь уже не зайдёт :)
Сервер работает довольно шустро, но при небольшом кол-ве юзеров, а когда их около 30, и кто-то запустил сложную задачу,
легко добиться сообщения "Кеш переполнен. Подождите", хотя при этом размер кеша достаточен.
Navision Server использует только блокировку на уровне таблицы, поэтому, если делается какой-то масштабный update/delete/insert в
важной таблице (например "Товарный журнал") то все ждут окончания всей операции, которая может продолжаться минутами.
Чтобы изменить данные в наборе строк, их нужно пробежать и для каждой строки программно поменять, что создаёт большой траффик.
Есть понятие транзакции. Даже если действие шло 5 мин. и на последней строчке прошло с ошибкой, все сделанные этим батчем модификации отменяются.
Механизм надёжен и работает по умолчанию. Есть возможность делать COMMIT в процессе выполнения батча.
Нет понятия "Дата с сервера". Все даты идут с клиента.
Приличных ODBC драйверов не встречалось. Те, что встречались, использовать нельзя, из-за вопиющей кривизны.
Изменять данные не через Navision-Client опасно, т.к. триггеры на таблицах в этом случае не работают.
Наверно единственный сервер, где размер базы нужно увеличивать вручную (!), и следить за свободным местом.
Нагружает CPU слабо т.к. практически отсутствуют собственно-вычисления. Ведёт себя стабильно т.к. просто устроен.
Стабилен. Потери данных наверно редкое явление.

MSSQL
часто используется в качестве СУБД. Как правило из-за возможностей наращивания производительности и построения отчетности.
При маленьких объёмах данных всё работает хорошо. Но на больших объёмах (>50Гб) ситуация резко меняется, т.к. MSSQL не любит широких таблиц с сотней полей, из которых большинство - текстовые... :)
Скорость роста базы - примерно 1.5 от аналогичной в Navision Server.
Никакой логики на стороне сервера не хранится. Никаких ХП , view, триггеров. Вся логика выполняется на клиенте. Как собственно в большинстве аналогичных систем.
Ввиду сложной организации данных, делать репортинг внешними средствами - занятие не из приятных. Даже на MSSQL.

Navision - двухзвенка. Иногда за 3-е звено некоторые пытаются выдать Navision Application Server, который не более чем клиент без интерфейса.
Запускается как служба и служит для выполнения репликации и заданий по расписанию. Работает чуть быстрее обычного клиента.

Репликации:
Репликции - только On-Line, т.е. нужна "прямая видимость" в лок.сети.
Стандартная репликация - глючная и дорогая. Но неплохо работает репликация от Lanstainair входящая в Адд-Он для розницы.
Случаи потерь при репликации есть, но это случается с умеренной частотой, т.е. "жить можно".

Интерфейс:
Обычный Win-MDI. Спартански прост, довольно удобен, хотя местами примитивен:
+ Навигация по контролам стрелками в любом направлении и с комбинациями Alt и Ctrl.
+ Вычисление значений прямо в поле: 2+3 внесёт 5
+ Из поля можно прыгнуть в его источник, например из суммы получить строки, её формирующие. Это стандартное поведение для всех полей.
+ Прямо в поле можно наложить фильтр и получить список согласно фильтра. Фильтры удобные, но только в пределах этого поля. Например field1<>field2 сделать можно только в отчете.
+ Из любого грида можно скопировать в EXCEL через буфер.
+ Любой контрол и поле могут иметь мультиязычную подпись, в .т.ч. в отчётах.
+ Довольно удобный автопоиск.

- Невозможно сделать сложную форму со сложным наборами данных в каждом из контролов.
Изначально интерфейс ориентирован для показа данных из одной таблицы либо по принципу шапка-строки, но не более.
- Нет такого контрола, как дерево, хотя его неплохо заменяют гридом с отступами и жирным выделением.
- Весьма сложно отобрать записи по некоторому условию из другой таблицы. Только через временную таблицу.
- Добавить нестандартный контрол можно только через OLE.
- Внутрений репортер прост, но примитивен. Некоторые задачи делаются мучительно.
- Сортировка возможна только по существующему индексу.
- Поля с датами не содержат выпадающего календаря, хотя существует доработка: формочка а-ля календарь.
- В принципе невозможен Drug-n-Drop
- Иногда встречаются неясные внутренние ошибки (Ошибка ХХХ в модуле ХХХ), но возможно это не проблемы интерфейса.

Программирование:
Встроенный паскалеподобный язык C/AL, хотя нет многих фундаментальных паскальных команд, например BREAK/CONTINUE.
Легко освоить. Много ограничений. Многие свойства контролов не меняются программно.
Всё программирование сводится к построчной навигации по данным (NEXT, FIND, SKIP, SETFILTER), поэтому чуть-чуть напоминает ФОКС-ПРО.
В связи с тонкостями лицензирования есть проблема при создании форм, отчетов, таблиц - их надо покупать и они должны быть в интервале
предусмотренных вашей лиценцией номеров (все объекты имеют внутр. ID). Стоимость новых таблиц существенна.
Для обмена данными через ТХТ-файлы есть понятие DATAPORT. Довольно удобно, но... импорт/экспорт ....в DOS-кодировке. :)
Например украинские буквы I,i не имеют инвариантных аналогов в DOS-кодировке. Чтение файла в Вин-кодировке представляет сложность.
Замена/Дополнение программного кода делается легко и "на лету". Можно выгрузить нужные модули/формы/репорты в спец-файл и "накатить"
его на другую базу. Нельзя удалить поле, если в нём есть данные. Нет понятия NULL. Числовые поля по умолчанию 0, Текстовые ='', Дата=0.
Мощная штука - FLOWFIELD (SIFT). Виртуальное поле, данные в котором по установленным условиям вычисляются почти мгновенно по данным из другой таблицы.
Большинство вычислений в Navision сводятся к вычислению значений этих полей. Например весь товарный учёт основан именно на этом и например,
складское наличие это сумма всех операций с начала работы системы. Даже при миллионах записей механизм работает очень быстро.
Для работы такого поля необходим индекс со всеми полями, участвующим в условии. Суммировать можно только одно поле и поэтому выражение типа sum(Field1*field2) недопустимо.
Несмотря на простоту програмирования, делать изменения непросто и небыстро , т.к. структура данных перенасыщена таблицами и полями,
полное назначение которых могут не знать даже Navision-гуру. Документация помогает слабо, т.к. суть и логика данных может быть уже давно изменена "неизвестным художником от ERP".
Даже в демо-базе большое кол-во ошибок и недоделок.
Обращаться к двум и более физич.базам почти невозможно, хотя нечто подобное делает репликация, но это немного другой случай :)

Администрирование:
Основная проблема: бешенный рост размера базы. Ключевые таблицы (товарный фурнал, журнал стоимости) имеют огромное кол-во полей и индексов.
и могут составлять 60% от всего объема данных. 70% полей обычно незаполнены.

Перспективы и Вердикт (ИМХО):
К нам на праздник автоматизации Navision немного опоздал. :)
Из-за проблем с масштабируемостью его вряд ли можно рекомендовать как корпоративную платформу (хотя сейлсы рекомендуют по невежеству).
Хотя для небольших и нерастущих :) предприятий он вполне приемлим при правильном внедрении.
Для мелких фирм он безумно дорог. Найти золотую середину - крайне непросто.
Новые версии выходят редко и версия 3.7 может быть последней. Развитие Navision со стороны Microsoft начинает сокращаться в пользу более
перспективных продуктов. Поэтому выбирая систему "на вырост" следует сто раз отмерить, прежде чем один раз отрезать.

2 mazzy

По поводу выхода версии 4. Виноват ! :( За новостями слежу нерегулярно.
Пресс-релизы то довольно новые... Однако до использования этой самой версии на территории ExUSSR ещё далеко. Предстоит длительная локализация.
А тут ещё в 3.6 порядка не навели... При переходе от версии к версии могут появится подводные камни. На это может уйти не один год. Будете отрицать ?
Жаль, что на статью про сокращение (но не прекращение) поддержки ссылку запамятовал. И про Акзапту я ни слова не говорил. И ИМХО дважды написал не даром. Это мой ИМХО-вердикт и моё субъективное мнение. Напишите свой ИМХО-вердикт ! А не только ссылки. Я убеждён, что Navision очень скоро почувствует серьёзнейшую конкуренцию с новыми отечественными системами.
И потом... пресс-релизы от Microsoft это замечательно. Но это реклама. Факты с рекламой совпадают, увы, реже, чем хотелось бы...
Фразы типа "Work and Grow the Way You Want" уже как песок на зубах.
И давайте как-то корректнее обвинять др. др. в невежестве.
>> Воспринимайте базу данных Навижина как OLTP и OLAP в одном флаконе.
>> Почитайте про SIFT.
Это Ваша фраза про работу Navision+MSSQL ! Наверно согласятся все, что звучит она, мягко говоря... немного невежественно. Особенно про технологию SIFT применительно к MSSQL. Будем считать это просто эмоциями.
Поверьте, ничего личного. Я Вас уважаю, как специалиста. Слушал Ваши лекции :) Я также беру в учёт, что Вы лицо заинтересованное, т.к. имеете прямое отношение к внедрению продуктов MBS, поэтому нападки на эти самые продукты воспринимаете близко к сердцу. Возможно на Вашем месте я поступал бы точно также... :)
Лучше напишите, Please, подробный пост по Акзапте. Всем будет интересно.
Не ссылки на тонны полупустой документации, а именно подробно, но кратко :)
Одна страничка инфы от Специалиста полезнее вороха ссылок на рекламные ресурсы.
Только чур, недостатков не скрывать. Это не честно.
Будем объективны и сдержаны в заявлениях ! Надеюсь, что сочтёте этот пост вежливым и объективным.

mazzyа как же функционал? :)
Звучит провокационно... :) :) :)
На этот вопрос не буду отвечать принципиально. В стандартной поставке (CRONUS-Россия) он весьма беден, и использовать его без серьёзных доработок нельзя. Отчетная часть - вааще голяк ! (Может существует другая "стандартная поставка" ? Просветите !)
Если кому-то и удалось полноценно внедрить SUBJ, то это путём больших собственных доработок. Самодельный ф-л обсуждать нет смысла, т.к. он специфичен и зачастую представляет основную коммерческую ценность внедренцев :)
Внедрить Navision без помощи внедренцев - маловероятный факт, поэтому попрошу не трогать тему дешевизны решения.
Даже в варианте для малого бизнеса (до 10мест) стоимость ВСЕГДА не менее пяти знаков УбитыхЕнотов :) Применение репликации съедает 1коннект.
В случае зависания клиента, его сессия может зависнуть и остаться форева (в опции Navision Server). Для её снятия надо просто перегрузить Nav-сервер. :)
Если и автоматизировать что-то на Navision, то уж начинать надо никак не с бухгалтерии. Там рулит 1С. Поэтому обычно автоматизируют Упр.Уч. А для него 10мест - пшик.

Это при том, что малый бизнес норовит даже 1С брать за 1.5$ на раскладке... :) Проза жизни. Потому, что стандартная 1С вполне юзабельна для своего круга задач, даже купленная на раскладке в метро. :)

2 ALL
Повторюсь : всё ИМХО! Не согласны ? Дайте свой ИМХО, причём желательно со своими проверенными аргументами, а не с гиперссылками на Microsoft и репликами "ВРАНЬЁ !". Людям свойственно ошибаться. Для того и обсуждаем, чтоб найти истину, а не врагов. :)
Дерзайте ! :)

Слишком уж типичная эта беда. ЧЕРЕЗЧУР ТИПИЧНАЯ ! Для всех систем.
Отсюда и недоверие к возгласам восхищения в пользу той или иной системы. И остаётся от "восхищения" только "хищение".
Денег, времени, надежд и пр. :)
Хотя и реплики tygra иногда очень категоричны, тут с ним можно согласиться... ИМХО.
Нет дыма без огня (с)