платформа скалы

И что из этого следует, надо отказаться от Скалы и перейти на что? На самописный софт?
Я ненавижу старые лады, но самописный софт — это транспортное средство, сродни тому, на котором летал барон Мюнхаузен (пушечное ядро): возможно, это очень быстро, очень круто, но без гарантии прибытия именно в нужную точку и того, что Вы останетесь живы

А кроме того, Ваши системщики:

Во-первых, лезут не в своё дело: Это не технический вопрос!!! Поэтому он не к техническим гуру. Уж во всяком случае не Вашим системщикам решать эти вопросы, их просто следует поставить на место!
Во-вторых, сравнение хоть и эффектно, но абсолютно некорректно
В-третьих, платформа не может рассматриваться в отрыве от функциональности. Не так важно на чём привезут ракету, важно, чтобы эта ракета была способна поразить цель. У новой ауди есть ракеты собственного производства?

И это настораживает. Во первых кто будет внедрять этот продукт в России? Во вторых, сколько нужно будет ждать помощи специалистов при нештатных ситуациях, что такого не будет, не верю. И может ли ваше предприятие позволить себе простой в течении этого времени? И самое главное сможет ли эта программа выдавать данные для Российских отчетов в налоговые и прочие фискальные органы?

Моё личное мнение, которое я никому не навязываю: Если решение предлагается со стороны материнской компании, его и принять должны именно там, а до сведения дочерней просто довести. В любом случае решение должно приниматься не по принципу — менять тогда, когда можно заменить, а по принципу — менять только тогда, когда НЕЛЬЗЯ НЕ заменить!!!

Интерфейс — это последнее, что должно приниматься в расчет

Вопрос, на мой взгляд, чисто технический и не имеет никакого отношения к функциональному. С ним надо разобраться один раз и навсегда и при этом не важно, с платформой это связано или с рельсами. Если с платформой — её должны починить. У нас, например, такого не происходит.

На мой взгляд, это вопрос управленческий, вопрос взгляда на ERP систему. Говоря "самописный" я подразумеваю не собственно нечно написанное "на коленке". Вопрос в том, будет ли это стандартная версия, настраиваемая с помощью параметров, поддерживаемая поставщиком и/или производителем или нечто "уникальное", доработанное под конкретную "уникальную" организацию, какой бы уникальной она ни была на самом деле. Во втором случае Ваша система не будет поддерживаться никем, кроме Васи Пупкина в рваных джинсах, который может требовать зарплаты в 100 тысяч чистыми плюс бонусы. Если организация готова к этому, а её руководство отчётливо понимает последствия такого шага, значит они делают осознанный выбор и им в данном случае виднее, на то они и руководство.

Мы вполне послушная дочерняя компания но пока мы можем рассуждать

когда до нашего сведения доведут начнется второй этап внедрения который учитывая удаленность может стать резиновым

Может быть это несколько не в тему но
недавно в Мурманском поезде из соседнего купе я слышала очень славный разговор
Начальник какого- то отдела горнодобывающего предприятия жаловался на внедрение программы оракл
одна из причин жалоб что не взяли группу внедренцев которая работала на Магнитке и где за 10 лет они ее успешно внедрили

если взять такие темпы то к концу может сдохнуть либо Скала либо ее конкурент либо предприятие

Что касается последнего пункта- Васи Пупкина

к сожалению когда Вы находитесь в сутках езды от Питера или Москвы или чего нибудь кроме леса преимущества Скалы начинают носить относительный характер

то есть пока не вырастишь своего Васю Пупкина цена 100 тысяч чистыми является преуменьшенной
и у него есть все шансы на норковые джинсы

УЕ пойдёт? Если УЕ (100 тысяч чистыми. Можно даже в год.), готов вести переговоры

Но всё-равно они должны быть рваными

Это скорее всего происходит не из-за платформы, а из-за особенностей настройки ваших сетей и/или оборудования, очень похоже на разрыв соединения с SQL Server’ом и, как следствие, некорректное завершение сессии, у нас на терминальном сервере подобное происходило из-за "хранителя экрана", в общем надо искать причину, а не кивать на мифическую платформу.

Грамотная настройка и VBA проекты не будут слетать (копать надо в безопасности).
Мы победили это
А поначалу тоже мучались с ними.
_________________
Тот, кто задает вопрос, глупец в течение пяти минут, тот, кто его не задает, глупец всю свою жизнь.

Не из-за платформы?
Если бы при переходе с битрива на SQL Scala не поленилась и занесла бы критические обновления таблиц в транзакции, небыло бы необходимости "чистить хвосты"
Наблюдая трассировщиком за работой Scala невооруженным глазом видно что платформу просто "подключили" к SQL серверу без изменения принципа работы. Только в новой функциональности обращения в серверу выглядят более цивилизовано…

Scala 5.0/5.1 в версиях для Btrieve и SQL отличаются одной DLL. Первая версия для SQL появилась осенью 1997 г. Тогда в эксплутации была также версия для Access Manager (a-la DBF). На тот момент MS SQL 6.5 был не самой распространенной СУБД. В последствии была проведена работа по оптимизации работы, в т.ч. с привлечением специалистов Microsoft, что сказалось как на выполнении операций, так и на скорости отчетов. Фетишизм в отношении транзакций был у пользователей и 10 лет назад, так же, как и преклонение перед триггерами и т.п. Насколько мне известно, на том этапе даже MS советовала использовать сервер только как хранилище таблиц.

Вы считаете механизм транзакций фетишизмом!? А чем Вы считаете необходимость выяснения какие таблицы обновились, а какие нет после обрушения системы на этапе, например, обновления (что для Scala не редкость) и последующего исправления, часто вручную?

Посоветуйте своим системщикам побольше делом своим заниматься, а не теоретизированием по поводу старомодности платформ. У Скалы, конечно, есть свои проблемы (как, наверное, у любой программы), и иногда и проводки рвутся в том числе (по разным причинам), однако ни о каком "еженедельном", тем более "ежедневном"(!!!) зависании не должно быть и речи. Так что надо смотреть настройки сети, SQL сервер, корректность инсталляции Скалы, что-то другое — т.е. работать и искать причины проблем!
Пользователей у нас гораздо больше 50, производственный модуль есть, есть интеграция с другими приложениями.

Если бы не было "хвостов", то не надо было бы их чистить. Транзакции (сиквельные, а не транзакции главной книги), это круто, однако, наличие "хвостов" говорит о проблемах. Эти проблемы надо найти и устранить, тогда и чистить ничего не придется. Наверное, с транзакциями было бы проще, однако, и тогда нужно было бы найти проблему…