Внутри 1С мы (несколько сотен пользователей) используем 1С: Документооборот (в том числе и мобильного клиента Документооборота) для работы с почтой (внешней и внутренней), календарем, задачами, для коллективной работы с файлами и т.п.
Согласен, коррелирующие подзапросы непосредственно в тексте запроса были бы удобны. Сейчас такие задачи приходится решать через временные таблицы. Но тут мы приходим к стандартной задаче в жизненном цикле большого софтверного продукта. Есть запрос на новую функциональность (коррелирующие подзапросы). При этом задача, для решения которой требуется эта новая функциональность, уже решается существующей функциональностью (временными таблицами), пусть и не так изящно. А еще у нас есть список других запросов на новую функциональность, в том числе и ту, которая решает задачи, до сих пор решения в рамках системы решения не имеющие.
Этим абзацем я иллюстрировал методику расставления приоритетов (новая функциональность, позволяющая решать НОВЫЕ задачи vs. новая функциональность, позволяющая решать задачи, уже имеющие решения в рамках существующей функциональности). Иногда первый тип новой функциональности получает более высокий приоритет, т.к. расширяет функциональность системы в целом; иногда — наоборот.
У вашего руководителя есть новые бизнес-идеи (работа в облаке, интерфейс Такси и т.п.). Именно их запросы вы и реализуете.
Коллега, есть идеи стратегические (работа в облаке, веб-клиент, мобильная платформа и т.п.). Без их реализации через некоторое время фирма будет обойдена конкурентами, лишится прибыли, снизит как следствие затраты на разработку, и в итоге станет хуже всем — и фирме, и партнерам/внедренцам, и клиентам. Не реализовывать стратегические идеи мы не имеем права.
Есть идеи тактические (импорт содержимого файлов в форматах Microsoft Excel 97-2010 и OpenDocument в табличный документ, использование логических выражений в описании поля выборки и в выражениях фильтрации результатов запроса (предложение ГДЕ), использование функций и временных таблиц при работе с внешними источниками данных и т.д. и т.п) — их мы тоже реализуем. Я сожалею, честно, без дураков, что та функциональность, которая необходима лично вам, до сих пор не реализована.
И партнерский семинар и ваш выход на площадку habrahabr это чистый пиар, без желания получить обратную связь
Не скажите. Несмотря на что, что на Хабре мы недавно, уже от нескольких пользователей получили в личную переписку полезный фидбэк, который планируем использовать в работе. Про семинар даже и не говорю.
поэтому я и написал, что разработчикам платформы нельзя отмежеваться от разработчиков флагманской типовой конфигурации, что вы пытались сделать несколько постов назад
Где я такое писал? Дайте пожалуйста ссылку или цитату.
Как например ваши расширения помогут, если для реализации требований клиента необходимо внести изменения в типовой функционал (модули), который потом будет обновляться?
Повторюсь, на проектах внедрения (не только 1С) всегда есть этап Performance Tuning, то есть тонкая настройка системы для конкретного клиента. Ваша платформа таких возможностей не предоставляет
Конфигурация предоставляется в исходных кодах. Есть «Замер производительности» в Конфигураторе, есть КИП — можно выявить узкие места, поменять исходный код и свойства объектов конфигурации.
Проверять нужно на клиент-серверной базе SQL Server УПП 1.2-1.3.
Спасибо, теперь понял, о чем речь.
Да, такое поведение платформы исправили в 8.2 (если не ошибаюсь — 8.2.14, «Запрос, содержащий оператор В с множественными операндами, в подзапросе которого есть упорядочивание, может быть исполнен, если из подзапроса нет обращений к полям внешнего запроса.», есть в V8Update.htm). Исправление было сделано в рамках унификации работы с СУБД, т.к. предыдущее поведение не работало на всех СУБД.
Ваш запрос можно модифицировать так, чтобы он заработал на 8.2:
ВЫБРАТЬ
Товары.Ссылка,
ЦеныТоваров.Цена
ИЗ Справочник.Номенклатура КАК Товары
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныТоваров
ПО
(ЦеныТоваров.ТипЦен) В (
ВЫБРАТЬ ПЕРВЫЕ 1
Подчиненные.ТипЦен
ИЗ РегистрСведений.ЦеныНоменклатуры КАК Подчиненные
ГДЕ
Подчиненные.Номенклатура = Товары.Ссылка
УПОРЯДОЧИТЬ ПО
Период)
Сделайте поиск — «опрос по средствам разработки». Оказывается опрос был в начале 2013 года, то есть почти три года прошло.
Сделал, посмотрел. Все 10 страниц читать не стал, пробежал первые три. Часть пожеланий реализована в Enterprise Development Tools (но тут придется подождать его готовности). Были пожелания ускорить работу с хранилищем конфигураций — работаем в этом направлении, почти каждую версию платформы есть доработки в этом направлении.
Надеюсь, не будете обвинять нас в том, что мы не реализовали ВСЕ пожелания из опроса?
Назовите разработанную с 0 конфигурацию по сложности и функциональности сопоставимую с ERP 2 или хотя бы УПП.
А есть потребность в конфигурациях такого масштаба? Можете привести пример? Я серьезно, вопрос не праздный.
Давайте посмотрим шире — в мире вообще мало случаев, когда на аналогичных платформах партнерами (а не самими производителями платформы) создавались решения масштабов ERP. И не потому что платформы плохи, а потому что это а) долго и дорого, может себе позволить только крупная компания и б) как правило такое/похожее по функциональности решение уже сделал производитель платформы, и проще доработать его, чем писать своё.
Уж расширения точно сделаны не для внедренцев. Это механизм, необходимый для полноценной работы другой вашей мечты — работе в облаке. Для проектов внедрения — никак не пригодится.
Почему так считаете? Мы переносим в расширения все больше и больше объектов. Уже видел случаи переноса внедренцами части модификаций на местах в расширения с целью облегчить переход на новые версии. Что может помешать использовать расширения внедренцам? Пока — малое количество объектов, поддерживаемых расширениями. Но их будет все больше. Так что проблем не вижу. Если их видите вы — опишите пожалуйста.
Один из вариантов — не давать сертификат 1С: Совместимо для конфигураций, которые используют такие конструкции. Это хоть какой то выход.
У меня есть некоторый опыт написания платформ для нескольких ERP (не связанный с 1С). Могу сказать по своему опыту — введение такой «полуподдерживаемой» функциональности в платформу через пару версий их активного использования прикладными разработчиками приводит к проблемам в поддержке и развитии платформы, которые сводят на ноль все преимущества этой функциональности. Это даже если платформа не публичная и ее используют только прикладные программисты внутри компании. Если же платформа публичная, как у 1С — количество неприятностей можно смело возводить в квадрат (а то и в куб).
Попробуйте использовать в () поля из присоединяемой таблицы, а в подзапросе тоже выбирать данные из присоединяемой таблицы, а не из основной и все встанет на свои места
Можете написать такой запрос для демо-базы, который работает на 8.1 и не работает на 8.3?
Мне действительно интересен этот вопрос — «отваливают» функциональность довольно редко, хотелось бы разобраться.
Таких топиков полно, только без участия разработчиков платформы и конфигураций. Смысл?
В прошлом году подняли вопрос о том, чего не хватает в платформе. Не хотите обсудить, что из этого сделали?
О каком вопросе речь, напомните пожалуйста. Возможно я не в курсе.
Ну и надо помнить что год — не то чтобы очень большой срок для софтверного проекта в миллионы строк кода.
Ваша платформа, не смотря на ее технологичность без типовых конфигураций никому не нужна.
Это утверждение можно смело отнести к большинству платформ, аналогичных «1С: Предприятие». Бизнесу (в массе своей) не нужен инструмент разработки бизнес-приложения как таковой — ему нужно бизнес-приложение, решающее его, бизнеса, задачи. Поэтому мы делаем и платформу, и типовые конфигурации.
А платформу как таковую для создания тиражных конфигураций для различных областей бизнеса используют партнеры; то, что 1С-совместимых конфигураций создано более тысячи, говорит, на мой взгляд, о соответствии платформы решаемым ей задачам.
Если в компании нет 1С, без качественной конфигурации, покрывающей хотя бы половину потребностей — она там не появится.
Отсутствие заботы разработчиков платформы и разработчиков конфигурации о тех, кто занимается внедрением и просто доработкой типовых конфигураций. Вы делаете некоторое общее решение, которое покрывает какой-то процент потребностей конечного пользователя. Одна из ваших задач — предоставление средств для упрощения доработок.
Мы это делаем — вот, вот, и вот, и еще много другого. Но вы же понимаете, что ресурсы, даже наши, ограничены, и мы не в состоянии выполнить все потребности всех внедренцев сразу (тем более, что потребности эти нередко прямо противоположные).
Есть СУБД которые поддерживают их нативно и вместо того, чтобы сделать либо реализацию (пусть медленную) для остальных СУБД или просто разрешить использовать ее только при доработках, вы обрубаете это возможность вообще.
Делать так — значит ступать на очень скользкую дорогу, что весьма рискованно как для нас, так и для партнеров и внедренцев.
1.1. до 8.2 была возможна следующая конструкция
СОЕДИНЕНИЕ Таблица1 КАК Строки1
ПО (Поле1, Поле2) В (
ВЫБРАТЬ ПЕРВЫЕ 1
Поле1, Поле2
ИЗ Таблица1 КАК Строки2
УПОРЯДОЧИТЬ ПО
Поле1, Поле2)
это не работало на всех СУБД кроме SQL Server. В 8.2 (видимо решили, что это унизит Oracle) эту возможность обрубили и оставили возможность использовать только одно поле.
Вы уверены, что это не работает в 8.3?
Я только что попробовал — вот такой запрос (с условием соединения идентичным, если не ошибаюсь, вашему) работает на демо-базе.
ВЫБРАТЬ
УчетНоменклатуры.Номенклатура,
УчетНоменклатуры.Склад,
УчетНоменклатуры.Количество,
Валюты.Ссылка
ИЗ
РегистрНакопления.УчетНоменклатуры КАК УчетНоменклатуры ЛЕВОЕ СОЕДИНЕНИЕ
Справочник.Валюты КАК Валюты ПО
(УчетНоменклатуры.Номенклатура, УчетНоменклатуры.Склад) В
(ВЫБРАТЬ ПЕРВЫЕ 1
УчетНоменклатуры.Номенклатура,
УчетНоменклатуры.Склад
ИЗ
РегистрНакопления.УчетНоменклатуры КАК УчетНоменклатуры
УПОРЯДОЧИТЬ
ПО УчетНоменклатуры.Номенклатура,
УчетНоменклатуры.Склад)
1.2. Получение номера строки выборки:
SQL Server, ROW_NUMBER, 2005
ROW_NUMBER() не работает в SQL2000, а мы его до сих пор поддерживаем.
2. Если вы будете продолжать делать упор на то, что производительность встроенного языка не важна
Такого не утверждалось. Говорилось, что ситуаций, где производительность именно встроенного языка становится критичной — сравнительно немного. Мы такие ситуации анализируем.
По таким вопросам как ООП, производительность встроенного языка, развитие языка запросов должны быть постоянно открытые топики на партнерке с обсуждением всех заинтересованных сторон.
У вас есть доступ в партнерский форум? Открывайте топики, устраивайте дискуссии, мы только «за».
Сейчас разработчики типовых конфигураций вообще не участвуют в топиках по платформе
Вы имеете в виду партнерский форум?
Разработчикам типовых на партнерском форуме хватает работы в профильных темах.
Для связи с разработчиками платформы используются другие каналы, благо сидим мы на соседних этажах.
1. Я написал вам, что мешает сделать возможность использовать функциональность конкретной СУБД при внедрении, хотя бы те возможности, которые не противоречат встроенному языку (например кореллированные подзапросы).
Согласен, коррелирующие подзапросы непосредственно в тексте запроса были бы удобны. Сейчас такие задачи приходится решать через временные таблицы. Но тут мы приходим к стандартной задаче в жизненном цикле большого софтверного продукта. Есть запрос на новую функциональность (коррелирующие подзапросы). При этом задача, для решения которой требуется эта новая функциональность, уже решается существующей функциональностью (временными таблицами), пусть и не так изящно. А еще у нас есть список других запросов на новую функциональность, в том числе и ту, которая решает задачи, до сих пор решения в рамках системы решения не имеющие. И есть ресурсы и временнЫе рамки проекта. Понятно, что при формировании списка задач для новой версии больший приоритет получит критичная функциональность — та, которая позволит решать новые задачи или исправляет критичные ошибки.
Отвечая на ваш вопрос — «что мешает» — скажу так: наличие более приоритетных, с нашей точки зрения, задач.
До версии платформы 8.2 можно было использовать несколько полей в условии В соединения. В 8.2 это обрубили.
Можете привести пример запроса? Боюсь, что не понял вопроса.
По поводу ROW_NUMBER тоже хотелось бы комментарий увидеть.
Я правильно вас понял — вы предлагаете ввести в язык запросов функционал, который будет работать только в MS SQL и не будет работать в других СУБД?
2. В свое время в УПП появилась «оптимизация» корректировки стоимости на временных таблицах. РАУЗ в УПП и партии в ERP уже полностью на временных таблицах. Если бы не было проблем с производительностью встроенного языка — такое извращение никогда не появилось бы.
Да, вполне возможно что это одно из тех мест, где производительность именно встроенного языка становится «бутылочным горлышком». Будем чинить.
4. Логика СУБД это не только хранимые процедура, а выполнение разных расчетов на сервере. Из-за низкой производительности встроенного языка многие вычисления действительно выгоднее загнать во временные таблицы на сервер баз данных и затем вернуть результат.
Вы имеете в виду — вместо реализации логики на встроенном языке она реализуется в виде запросов к СУБД?
5. Я неправильно написал вопрос, вы как бывший сотрудник MBS должны помнить, чем отличается интернационализация в Navision от Axapta. Вот хочется как в Axapta
Когда-нибудь сделаем удобнее. Но это, повторюсь, вопрос приоритетов при выборе задач для реализации в очередной новой версии, как я уже писал выше.
Вообще зря я все это написал, это официальны блок и вряд ли вы ответите что-то отличное от того, что отвечаете на партнерке
Давайте тогда определимся с ожиданиями) Согласитесь, странно было бы, если на закрытом мероприятии (партнерском форуме) представители фирмы говорили одно, а на открытом ресурсе — принципиально другое, не так ли?
Скажу сразу — на все вопросы ответить сейчас не смогу.
1. С чем связан отказ от тонкой кастомизации работы с БД.
Вы же сами и ответили:
одинаковая работа приложения на всех 4-х СУБД, включая файловую версию
Если включать файловую версию — то на 5-ти СУБД.
2. Добавление бинарной трансляции p-кода. Вас не расстаивает, что Java-Script на веб-клиенте выполняется в тысячи раз быстрее встроенного языка?
Наверное, JavaScript при этом не делает все то же самое, что встроенный язык? Например, читает регистры из БД, делает отчеты и т.п.
Случаев, когда тормозит именно язык (а не доступ к БД например)- на деле не очень много. Выше уже обсуждали.
4. Судя по ERP 2 произошел крутой поворот в сторону выполнения всей логики на СУБД.
Коллега, можете пояснить примерами, что вы имеете в виду? Насколько знаю, хранимых процедур, специфичных для ERP, в конфигурации не появилось.
алгоритмические языки всегда более понятные и удобные для поддержки/доработки чем скрипты на SQL
Согласен 100%.
5. Когда наконец произойдет отказ от хранения текстов требующих перевода в отдельной части дерева конфигурации
Согласен, сейчас сделано не вполне удобно.
Опция «Редактирование текстов интерфейса» несколько облегчает работу, но целиком проблему не решает.
По Вашему обеспечить честно купившим не самую дешёвую x64 версию
Это х64 версия сервера, в прайс-листе так и написано.
сохранение прежней функциональности
Поясните пожалуйста, о чем речь? Про прежнюю функциональность.
может раскроете, в чем техническая сложность?
Сложность скорее не техническая; она — в объеме работ: введение нового компонента (х64 клиент) в структуру, встраивание в билд, создание тестов, документация, дистрибуция и т.д. и т.п. Все это — существенный объем работ. На который нужны ресурсы. А перед нами стоят и другие задачи, со своей стоимостью реализации и приоритетом. И вот на данный момент у других задач приоритет выше, чем у задачи создания клиента х64 под Windows.
Спасибо за понимание.
Но при всех достоинствах системы есть несколько негативных, на мой взгляд, моментов
Nobody's perfect
1. Отсталость среды разработки по сравнению с Eclipse, VS
Мы работаем в этом направлении, как вы наверное уже знаете.
2. Неразвитость языка программирования 1С. В него долгое время не вводились новые конструкции.
Чего именно не хватает в языке? Можно примеры?
3. Отсутствие модульного подхода, все решения получаются монолитными
Есть такое. У отсутствия модульного подхода есть как плюсы, так и минусы. Мы думаем в этом направлении, но планами пока делиться не готовы.
4. Официальная политика 1С на закрытость системы. Например, запрет и гонения за прямой доступ к базе данных, за декомпиляторы 1С, внешние средства-дополнения к конфигуратору.
Это типичная политика большинства вендоров. Надеюсь, вы понимаете, чем она вызвана. В особенности вот это:
"гонения за прямой доступ к базе данных"
Коллеги подсказывают: дело в том, что толстый клиент и сервер разделяют большое количество компонент, поэтому данную зависимость можно трактовать как «зависимость толстого клиента от компонент, содержащихся в пакете сервера». Разделить их, конечно, планируется, но существенной разницы в наборе устанавливаемых компонент все равно не будет.
А тонкий клиент, наоборот, не зависит ни от одного пакета платформы и является самодостаточным пакетом.
нельзя использовать два сетевых пользовательских ключа одинакового типа
Коллеги подсказали — это поведение связано с техническими ограничениями драйвера ключа (производитель Aladdin, ныне — SafeNet). Обойти это ограничение, к сожалению, нельзя.
Понял, спасибо.
Смогу вам развернуто ответить в начале след. недели, когда у меня будет шанс поговорить с командой лицензирования.
Извините за задержку — сейчас и у меня и у них плотный график :(
А скажите, плиз, в 8.3.6 отказоустойчевый сервер перестанет отказывать?
8.3.6 вышла в апреле, вы еще не успели посмотреть?
Извините что вопросом на вопрос )
В 8.3.6 было устранено несколько серьезных проблем с отказоустойчивостью, возможно, так проблема, которая была у вас, тоже решена.
И почему вы выбрали именно такой путь с лицензирования? а именно, что нельзя использовать два сетевых пользовательских ключа одинакового типа?
Тут, боюсь, не смогу вам ответить сразу, надо проконсультироваться с командой. Чтобы не было недопонимания — можете дать ссылку на описание схемы лицензирования, про которую вы пишете?
И сразу оговорюсь — не могу обещать, что исчерпывающе отвечу на ваш вопрос, в том числе и по соображениям возможной конфиденциальности.
Про крупный рынок сказать проще — там много исследований проводится.
По количеству внедрений (информация от TAdviser) на 2015 год картина такая:
Если мерять по деньгам — картина несколько другая, т.к. внедрение SAP стоит сильно дороже внедрения 1С. Сходу нашел только за 2013 год в РБК (повторюсь, это объем в деньгах! не в количествах внедрений или рабочих мест):
По малым внедрениям статистики быстро найти не смог.
Выходит, обвинения ваши голословны. Давайте мы тогда добросовестность бизнеса будем обсуждать с теми, кто сам ведет себя этично. Этот пост про технологии, если вы можете что-то сказать по существу, а не только переходить на личности и троллить по профилю в линкедине — говорите, не можете — тролльте где-нибудь в другом месте.
Этим абзацем я иллюстрировал методику расставления приоритетов (новая функциональность, позволяющая решать НОВЫЕ задачи vs. новая функциональность, позволяющая решать задачи, уже имеющие решения в рамках существующей функциональности). Иногда первый тип новой функциональности получает более высокий приоритет, т.к. расширяет функциональность системы в целом; иногда — наоборот.
Коллега, есть идеи стратегические (работа в облаке, веб-клиент, мобильная платформа и т.п.). Без их реализации через некоторое время фирма будет обойдена конкурентами, лишится прибыли, снизит как следствие затраты на разработку, и в итоге станет хуже всем — и фирме, и партнерам/внедренцам, и клиентам. Не реализовывать стратегические идеи мы не имеем права.
Есть идеи тактические (импорт содержимого файлов в форматах Microsoft Excel 97-2010 и OpenDocument в табличный документ, использование логических выражений в описании поля выборки и в выражениях фильтрации результатов запроса (предложение ГДЕ), использование функций и временных таблиц при работе с внешними источниками данных и т.д. и т.п) — их мы тоже реализуем. Я сожалею, честно, без дураков, что та функциональность, которая необходима лично вам, до сих пор не реализована.
Не скажите. Несмотря на что, что на Хабре мы недавно, уже от нескольких пользователей получили в личную переписку полезный фидбэк, который планируем использовать в работе. Про семинар даже и не говорю.
Дайте пожалуйста ссылку или цитату. Не припоминаю, что я писал подобное.
Как мне кажется, вы еще не знаете, о чем идет речь, но уже выносите суждение.
Где я такое писал? Дайте пожалуйста ссылку или цитату.
Про это рассказывали на октябрьском семинаре.
Конфигурация предоставляется в исходных кодах. Есть «Замер производительности» в Конфигураторе, есть КИП — можно выявить узкие места, поменять исходный код и свойства объектов конфигурации.
Спасибо, теперь понял, о чем речь.
Да, такое поведение платформы исправили в 8.2 (если не ошибаюсь — 8.2.14, «Запрос, содержащий оператор В с множественными операндами, в подзапросе которого есть упорядочивание, может быть исполнен, если из подзапроса нет обращений к полям внешнего запроса.», есть в V8Update.htm). Исправление было сделано в рамках унификации работы с СУБД, т.к. предыдущее поведение не работало на всех СУБД.
Ваш запрос можно модифицировать так, чтобы он заработал на 8.2:
Сделал, посмотрел. Все 10 страниц читать не стал, пробежал первые три. Часть пожеланий реализована в Enterprise Development Tools (но тут придется подождать его готовности). Были пожелания ускорить работу с хранилищем конфигураций — работаем в этом направлении, почти каждую версию платформы есть доработки в этом направлении.
Надеюсь, не будете обвинять нас в том, что мы не реализовали ВСЕ пожелания из опроса?
А есть потребность в конфигурациях такого масштаба? Можете привести пример? Я серьезно, вопрос не праздный.
Давайте посмотрим шире — в мире вообще мало случаев, когда на аналогичных платформах партнерами (а не самими производителями платформы) создавались решения масштабов ERP. И не потому что платформы плохи, а потому что это а) долго и дорого, может себе позволить только крупная компания и б) как правило такое/похожее по функциональности решение уже сделал производитель платформы, и проще доработать его, чем писать своё.
Почему так считаете? Мы переносим в расширения все больше и больше объектов. Уже видел случаи переноса внедренцами части модификаций на местах в расширения с целью облегчить переход на новые версии. Что может помешать использовать расширения внедренцам? Пока — малое количество объектов, поддерживаемых расширениями. Но их будет все больше. Так что проблем не вижу. Если их видите вы — опишите пожалуйста.
У меня есть некоторый опыт написания платформ для нескольких ERP (не связанный с 1С). Могу сказать по своему опыту — введение такой «полуподдерживаемой» функциональности в платформу через пару версий их активного использования прикладными разработчиками приводит к проблемам в поддержке и развитии платформы, которые сводят на ноль все преимущества этой функциональности. Это даже если платформа не публичная и ее используют только прикладные программисты внутри компании. Если же платформа публичная, как у 1С — количество неприятностей можно смело возводить в квадрат (а то и в куб).
Можете написать такой запрос для демо-базы, который работает на 8.1 и не работает на 8.3?
Мне действительно интересен этот вопрос — «отваливают» функциональность довольно редко, хотелось бы разобраться.
О каком вопросе речь, напомните пожалуйста. Возможно я не в курсе.
Ну и надо помнить что год — не то чтобы очень большой срок для софтверного проекта в миллионы строк кода.
Это утверждение можно смело отнести к большинству платформ, аналогичных «1С: Предприятие». Бизнесу (в массе своей) не нужен инструмент разработки бизнес-приложения как таковой — ему нужно бизнес-приложение, решающее его, бизнеса, задачи. Поэтому мы делаем и платформу, и типовые конфигурации.
А платформу как таковую для создания тиражных конфигураций для различных областей бизнеса используют партнеры; то, что 1С-совместимых конфигураций создано более тысячи, говорит, на мой взгляд, о соответствии платформы решаемым ей задачам.
Не всегда это так; например, в компании Вкусвилл система управления написана на 1С с нуля.
Мы это делаем — вот, вот, и вот, и еще много другого. Но вы же понимаете, что ресурсы, даже наши, ограничены, и мы не в состоянии выполнить все потребности всех внедренцев сразу (тем более, что потребности эти нередко прямо противоположные).
Делать так — значит ступать на очень скользкую дорогу, что весьма рискованно как для нас, так и для партнеров и внедренцев.
Вы уверены, что это не работает в 8.3?
Я только что попробовал — вот такой запрос (с условием соединения идентичным, если не ошибаюсь, вашему) работает на демо-базе.
ROW_NUMBER() не работает в SQL2000, а мы его до сих пор поддерживаем.
Такого не утверждалось. Говорилось, что ситуаций, где производительность именно встроенного языка становится критичной — сравнительно немного. Мы такие ситуации анализируем.
У вас есть доступ в партнерский форум? Открывайте топики, устраивайте дискуссии, мы только «за».
Вы имеете в виду партнерский форум?
Разработчикам типовых на партнерском форуме хватает работы в профильных темах.
Для связи с разработчиками платформы используются другие каналы, благо сидим мы на соседних этажах.
Согласен, коррелирующие подзапросы непосредственно в тексте запроса были бы удобны. Сейчас такие задачи приходится решать через временные таблицы. Но тут мы приходим к стандартной задаче в жизненном цикле большого софтверного продукта. Есть запрос на новую функциональность (коррелирующие подзапросы). При этом задача, для решения которой требуется эта новая функциональность, уже решается существующей функциональностью (временными таблицами), пусть и не так изящно. А еще у нас есть список других запросов на новую функциональность, в том числе и ту, которая решает задачи, до сих пор решения в рамках системы решения не имеющие. И есть ресурсы и временнЫе рамки проекта. Понятно, что при формировании списка задач для новой версии больший приоритет получит критичная функциональность — та, которая позволит решать новые задачи или исправляет критичные ошибки.
Отвечая на ваш вопрос — «что мешает» — скажу так: наличие более приоритетных, с нашей точки зрения, задач.
Можете привести пример запроса? Боюсь, что не понял вопроса.
Я правильно вас понял — вы предлагаете ввести в язык запросов функционал, который будет работать только в MS SQL и не будет работать в других СУБД?
Да, вполне возможно что это одно из тех мест, где производительность именно встроенного языка становится «бутылочным горлышком». Будем чинить.
Вы имеете в виду — вместо реализации логики на встроенном языке она реализуется в виде запросов к СУБД?
Когда-нибудь сделаем удобнее. Но это, повторюсь, вопрос приоритетов при выборе задач для реализации в очередной новой версии, как я уже писал выше.
Давайте тогда определимся с ожиданиями) Согласитесь, странно было бы, если на закрытом мероприятии (партнерском форуме) представители фирмы говорили одно, а на открытом ресурсе — принципиально другое, не так ли?
Вы же сами и ответили:
Если включать файловую версию — то на 5-ти СУБД.
Наверное, JavaScript при этом не делает все то же самое, что встроенный язык? Например, читает регистры из БД, делает отчеты и т.п.
Случаев, когда тормозит именно язык (а не доступ к БД например)- на деле не очень много. Выше уже обсуждали.
Коллега, можете пояснить примерами, что вы имеете в виду? Насколько знаю, хранимых процедур, специфичных для ERP, в конфигурации не появилось.
Согласен 100%.
Согласен, сейчас сделано не вполне удобно.
Опция «Редактирование текстов интерфейса» несколько облегчает работу, но целиком проблему не решает.
Это х64 версия сервера, в прайс-листе так и написано.
Поясните пожалуйста, о чем речь? Про прежнюю функциональность.
Сложность скорее не техническая; она — в объеме работ: введение нового компонента (х64 клиент) в структуру, встраивание в билд, создание тестов, документация, дистрибуция и т.д. и т.п. Все это — существенный объем работ. На который нужны ресурсы. А перед нами стоят и другие задачи, со своей стоимостью реализации и приоритетом. И вот на данный момент у других задач приоритет выше, чем у задачи создания клиента х64 под Windows.
Спасибо за понимание.
Спасибо! Мы стараемся)
Nobody's perfect
Мы работаем в этом направлении, как вы наверное уже знаете.
Чего именно не хватает в языке? Можно примеры?
Есть такое. У отсутствия модульного подхода есть как плюсы, так и минусы. Мы думаем в этом направлении, но планами пока делиться не готовы.
Это типичная политика большинства вендоров. Надеюсь, вы понимаете, чем она вызвана. В особенности вот это:
"гонения за прямой доступ к базе данных"
Вы как используемую память отслеживаете? Каким софтом?
А тонкий клиент, наоборот, не зависит ни от одного пакета платформы и является самодостаточным пакетом.
Возможно, некоторые объекты платформы в 8.3 поменяли реализацию и стали использовать больше памяти при определенных обстоятельствах.
Перешлите пожалуйста информацию по воспроизведению ошибки в нашу техподдержку на адрес v8@1c.ru
Коллеги подсказали — это поведение связано с техническими ограничениями драйвера ключа (производитель Aladdin, ныне — SafeNet). Обойти это ограничение, к сожалению, нельзя.
Смогу вам развернуто ответить в начале след. недели, когда у меня будет шанс поговорить с командой лицензирования.
Извините за задержку — сейчас и у меня и у них плотный график :(
8.3.6 вышла в апреле, вы еще не успели посмотреть?
Извините что вопросом на вопрос )
В 8.3.6 было устранено несколько серьезных проблем с отказоустойчивостью, возможно, так проблема, которая была у вас, тоже решена.
Тут, боюсь, не смогу вам ответить сразу, надо проконсультироваться с командой. Чтобы не было недопонимания — можете дать ссылку на описание схемы лицензирования, про которую вы пишете?
И сразу оговорюсь — не могу обещать, что исчерпывающе отвечу на ваш вопрос, в том числе и по соображениям возможной конфиденциальности.
По количеству внедрений (информация от TAdviser) на 2015 год картина такая:
Если мерять по деньгам — картина несколько другая, т.к. внедрение SAP стоит сильно дороже внедрения 1С. Сходу нашел только за 2013 год в РБК (повторюсь, это объем в деньгах! не в количествах внедрений или рабочих мест):
По малым внедрениям статистики быстро найти не смог.