Что это https://wonderland.v8.1c.ru/
1С выходит из тени)?

Неверландия наверное
Там сидят восьмерочники которые никак не вырастут

А каментить можно без авторизации?)

Да это вроде очень давно существует. Там то и нет ничего конкретного из зазеркалья, а так инфа для затравки о том как в 1с все хорошо и как много она может

(2) там вообще коментов нет

Одноэс может много
Главное не забывать ручками кеш чистить
Автоматизация, пля

Вчера выловил баг на 8.3.6 платформе. Я бы им запилил в бложек. В наименовании элемента справочника рядом стояли два символа: возврат каретки и перевод строки, длина строки по представлению учитывает оба, а после перевода в строку он схлопывается в одну кракозяблю, соответсвенно и длина строки становится меньше на 1 символ

А с какого в плоскую строку впихнули неплоск е символы

(5) Было бы хорошо, если 1с перешла на выпуск релизов с долговременной поддержкой, например как сделано во многих дистрибутивах линукс. Этот релиз вылизанный и безглючный, выше него типовые не прыгнут. А все плюшки в тестовых для разработчиков, и выход в широкие массы и в типовые при релизе стабильного дистрибутива. Не так как у линуксов раз в 2 года, ну а хотя бы раз в полгода...


Эх все это мечты да и только. Так что (6) будем ловить и дальше

(8)  концепция развития платформы мну непонятно
Делают какогото монстра всего для всего

(9) не, на самом деле концепция вполне интересная, но куда бежим не понятно. Сделали, зафиксировали, пошли дальше а на фиксированном работают люди. Я пока до сих пор не могу понять почему в 8.4.1 откинули кучу всего и за основу взяли 8.3.5, а остальное опять переписывать и опять наплодить багов? или не переписывать и забыть, тогда зачем это все наворотили?

(9) понятно, что на 77 все стабильно, как в склепе, так тоже нельзя

(7) не знаю, в 8ке такое возможно. Где-то отображается многострочно, а где-то кракозяблей

https://wonderland.v8.1c.ru/blog/novye-instrumenty-dlya-raboty-s-dvoichnymi-dannymi-obespechivayut-kak-posledovatelnyy-dostup-k-danny/

Неужели наконец-то? :)

(11) не все там стабильно, там тоже  глюков хватает, например с таблицами формы, да и просто с таблицами (в терминологии 8 "макет")

(14) это стабильные глюки, родные и домашние )))

(13) рано радуешься, может к 9.5 заработает нормально. Планируется не значит сделали и работает

(11) Точно точно, драйва не хаватает
ты не из тех, sлучаем кто пишет "#define TRUE FALSE //счастливой отладки суки" ? а то как в sклепе

(17) развитие 77 официально окончено, поэтому не цепляйся к словам. Да, при этом она останется прекрасным инструментом для ряда задач, где восьмерке делать нечего

(16) да я не то чтобы сильно радуюсь, у меня на этот случай C++Builder есть. Просто само по себе хорошо то, что понемногу появляются вещи, которые в нормальной разработке софта уже лет 30 как привычны и используются...

глядишь, к версии 9 битовые операции реализуют

(18) Речь не о клюшках, еsли ы понимаете о чем я

(18) 7.7 конечно сейчас сравнивать с 8.2+ смешно.. Там вообще откровенные ляпы и "слабые" приемы были. Вспомните реализацию радио кнопки, которую разработчики платформы слепили кое как, работает и ладно. Ну и не было тогда четкого различия объект-ссылка и код писали как есть.. Просто знали, что вот тут надо текущийэлемент() взять, а вот тут создать объект и заново поискать

(22) куда ж без магии

(22)
а что не так в радиокнопке?
и с текущим элементом вроде никаких проблем нет...

Разработчиков 7.7 надо отправить выживать на микроостров в Тихом океане с минимумом животного белка. Лет на 10.

(25) да ладно. Вполне годная была система для своего времени, да и сейчас ряд вопросов на ней можно решить быстрее чем свое приложение клепать

безусловно, что-то можно было сделать лучше. Но лучшее, как известно, враг хорошего. А если учесть сколько контор было автоматизировано и сколько бабла заработали причастные, то система существовала и существует однозначно не зря. Такое вот мое мнение.

(8) да, было бы норм и еще было бы круто, если бы обеспечили прямой доступ к скулю, и возможность создавать в метаданных - нативные таблицы скуля (регистр сведений не оправдал) - со своими же 1с-ными подписками - и возможностью ими управлять на уровне субд.  и балк инсерт, и опенхмл. и это, чтобы еще можно определять собственные вирт. таблицы.  
Реально, 1С сейчас ограничивает то, что они держатся за свой закрытый якобы стандарт хранения данных (1с++  и прямые запросы  конечно неслучайно создали). Но вместо этого - реально тормозит сама себя на рынке производительных систем, которые могут использовать весь спектр инструментов и хинтов субд. имхо.

(25) угу, а восьмерочников, которые живут на устаревшей 11.1 или не дай бог 10.3 - вообще отправить на Муруроа...

(29) Да и тех кто на 11.2 - тудаже

(28) "и возможность создавать в метаданных - нативные таблицы скуля (регистр сведений не оправдал) - со своими же 1с-ными подписками - и возможностью ими управлять на уровне субд.  и балк инсерт, и опенхмл."
- нафейхоа?

(31) Примерно затем же зачем и ВК со всякими внешними источниками данных, расширение возможностей платформы.

(31) для того чтобы иметь возможность оперировать данными большого объема, нет?
Или может быть вам не хотелось хоть раз применить truncate table для регистра АдресныйКлассификатор? . Серьезно - ни разу не хотелось?

(31) а заливать данные во временную таблицу - не через insert into - каждую строчку. А одним балком сразу захавать? Не было таких проблем при работе с внешними данными через запросы 1С?

(31) а срез последних на каждую дату - нравится каждый раз описывать? А остатки на каждую дату? А если бы можно было описать собственную вирт. таблицу, с параметрами,покером и прекрасными дивами? А потом эту собственную вирт. таблицу использовать да хоть в СКД. Нет? Не вдохновил?

а,еще прикол вспомнил. отбор  в списке - стандратно идет реально в списке, пока длины списка хватает. А когда перестает хватать - следующий сценарий - создается ВТ, в нее инсертится каждое значение (одно значение - один инсерт, 1с не умеет иначе), а уже потом лефт юнион и отбор по из нулл.
Ни разу с таким не сталкивались?

(36) *пока длины списка хватает. - длины текста запроса конечно.

А индексы-хотя бы можно было сделать - чтобы можно было напрямую в конфугрятнике описывать - не через порядок измерений, не через критерии отбора, а просто - напрямую - через свойство объекта мд Индексы.

(38) вот это - единственное стоящее из всего, что ты сказал

Особенно хотелось бы увидеть реализацию остатков на каждую дату

(33) для этого есть запись пустого набора регистра

(36) ты так говоришь, как будто это что то плохое

(38) пеши на партнерских. Я вот писал про Вт в дин. списках, спорил, доказывал. И вот, через 3 года, пождался 8.3.8

И слёзы радости катятся по щекам

(38) я думаю такая хрень появится

(43) сидят старые моряки в пабе и вспоминают - а помнишь как флот испанцев разбили? помню... И слеза по щеке...

(41) запись пустого набора это delete where 1 =1 . условно. может выполняться на порядки (осознаю что порядок - это в десять раз) медленнее чем truncate table.
В суть не вдавался, но предполагаю, что delete - физически удаляет записи с диска, а truncate  - не знаю, создает новую версию таблицы? факт в том что оно выполняется - мгновенно. А НаборЗаписей.Записать() - может длиться часами. Реально - проще регистр удалить, обновить базу и заново его вернуть в конфу.

(44) на самом деле, она конечно нужна, но не так, чтобы.

По строитель отсутствующих индексов в 90% замеров просит включить поле
Active
в кластерный индекс.

Остальное - решается

(46) физически с диска удаляют только специальные программы, это стоит знать.

(42) а что в этом хорошего. Что хорошего в том, что я не могу напрямую запрос прописать в отборе? А delete where (если примитивно). Нет, конечно, тут происходит бдение объектной целостности. Но объектная целостность - обеспечивается целостностью транзакостью а не обрезанностью возможностей запросов изменения данныех

(48) это не имеет отношения к вопросу. Я всего лишь предположил, "удаление с диска" - это скорее гипербола. Ну просто очень ,ну очень медленно это происходит. На уровне - вызывается бригада специалистов удаления с диска, которые анализируют весь диск, составляют тз на каждый байт, акты, собирают подписи, и только потом наконец очищают этот зловредный адресный классификатор.

(47) я говорил про delete. Там Active - не играет. А если играет - попробуйте его задейстовать?

(49) пеши на партнерских, я только за, если язык запросов расшириться, и это не будет расширение в сторону утырища СКД

(51) а я говорил про составные индексы :-)

Я только за те ситуации, когда толпы дятлов из подрастающего поколения будут верить базы еще больше и руководство будет чесать репу и относиться к 1с серьезней

Верить - херить

(40) реализация остатков на каждую дату - это фактически примитив.
коннект таблицы периодов - объединением - таблицы остатков  на начало периода - и движениями по дату (цепляя за дата движения меньше дата периода). вроде как то так.

(56) Так ты динамически это строить будешь?
Ну я смысл делать под это ВТ? Ну напиши свою процедуру на языке.

(53) ну а в составных индексах - active все равно последнее как правило в индексе, не думаю (предполагаю) что там большая задержка из за того что index scan вместо seek. То есть, если даже если этот признак не участвует в поиске, то все равно поиск происходит среди предыдущих (не знаю как это правильно назвать) заданных полей поиска.
Тут, я думаю, более критично стремление начинающих (или перешедших с 77) писателей - загнать все поля в измерения.
И почему я не могу построить индекс по ресурсу регистра. Пусть он - не уникальный, но вот у меня есть задача, частая - выполнять запросы именно по измерению или ресурсу.

(57) Под вирт. таблицы? Смысл? Было бы интересно, как минимум. Как максимум, если подобная задача не один раз в системе встречается - было бы правильно с точки зрения недублируемости кода. И опять же интересно - что это преимущество безусловное процедурного программирования - можно использовать на уровне запросов.

Вообще, я щетаю, что у бизнеса (в т.ч. у руководителей ИТ) в последние пару лет сложились завышенные ожидания от 1С и программистов.
От 1С они завышено ожидают простоты решений.
От программистов 1С - скорости разработки.

И это продолжается до тех пор, пока какая-нибудь УТ11 не приложит своим ЕРП ядром ожидающего видами запасов, учетом серий да или просто особенностями ведения тех же контрагентов с партнерами. Причем приложит опосредованно, через увеличевшееся время разработки программиста.

Застряли ребята в простоте УТ10.3, в которой все с полпинка делается и не могут адаптироваться.

Поднять штоли тему...

(58) "То есть, если даже если этот признак не участвует в поиске, то все равно поиск происходит среди предыдущих (не знаю как это правильно назвать) заданных полей поиска. "

Селективность выборки высока и остаточные предикаты поиска не оказывают большого влияния на быстродействие :-)

(60) скорость разработки - претензий не вызывает. Она более чем))
Понятно, что на любой базе(платформе) можно создать систему, неподъемную одному человеку. Да хоть на Экселе.
Но плюс 1с - в том что на 1с это сделать значительно сложнее (в силу среды разработки, отладчика, узнаваемой прикладной системы классов и пр, и др. )

(58) "Тут, я думаю, более критично стремление начинающих (или перешедших с 77) писателей - загнать все поля в измерения."

Нет ничего плохого в загоне всех полей в измерения, если это сделано с умом. Не стесняйтесь делать этого, даже когда это как бы не логично. Смотрите на таблицу с точки зрения кластерного индекса как набора измерений.

(61) хорошо сказано))

(63) нет. Нельзя смотреть на таблицу с точки зрения индекса. Таблица - это представление реальных данных (пусть и в виртуальной реальности) Прежде всего. Отсюда  появляются ключи (измерения и период в 1С), и признаки - реквизиты и ресурсы.
Если же загонять все в измерения - 1с будет послушно загонять все поля в индексы. Зачем.

(65) В большинстве своем РС менее частоменяемы, чем теже документы и РН, поэтому лишнее поле в индексе не повредит.
Кроме того, проще вытащить поле из кластерного индекса, а не делать дополнительно KeyLookup.

Конечно надо думать и прогнозировать. Однозначно в измерения нельзя добавлять длинные строки; с умом проектировать частоменяемые РС (Аналитики РАУЗ, к примеру).

(65) Херняс. Это былобы хорошо.
проектировать решение надо от реалий фактов хозяйственной жизни. а не от представления хз каких "документов".
то есть таблицы проектировать под факты хоз.жизни.
а все сотальное - получать агрегированием (например нафуя отдельный документ СЧФ? или отдельный документ Заявка и отдельный документ реализация С РАЗНЫМИ ТЧ - если в них (В ТЧ) - зафиксирован одинаковый факт хоз жизни)

ти частная схема данных имхо завсегда будет быстрее и проще чем универсальная схема данных.

(67) реализация и с/ф - это разные стороны объективности. Я кажется упоминал, намеренно, о вирт. реальности. В том числе подразумевая и мнимую реальность - налогового учета.
Каким образом эта схмема конфликтует с моим утверждением - не очень понятно.
Я просто хотел сказать, если обобщенно, что схема данных должна строиться на основе схемы учета, а если еще точнее, то схема данных должна строиться настолько оптимально, насколько это позволяет схема учета. А не запихивать все поля в измерения регистра остатков. или даже РС.

(68) разумеется. это уже чистая диалектика поперла. Универсальность всегда противоречит производительности.
И, если уж совсем обобщенно, мое мнение заключается в том, что  было бы в принципе неплохо, если бы 1С выдало в качестве инструментов совершенно неуниверсальные обеъкты, на основе которыех можно было бы построить производительную подсистему (а, в итоге, диалектика, и универсальную)

(66) лишнее поле в индексе - всегда будет лишним. Просто вот накой поле добавлять поле в измерение - если оно не измерение в парадигме 1С? Но. соглашусь, сильно хуже не будет. Просто будет чуть медленнее)) Это же не страшно))

(70) а в качестве плосокой таблицы не пойдет обычный РС..? или  Справочник?

(69) "что схема данных должна строиться на основе схемы учета,"
- угу, тоже самое и я криво сказал. А все сводится в типовых к построений не схемы данных, а схемы документов для учета документов.

(72) как в РС сделать insert без delete?
про сравочник - не говорю. как сделать для справочника delete from where ?
delete from select? delete top 10 ?

(73) документы - это условность. То есть - есть схемы данных, где не обязательно использовать документы. Правда, можно сказать - что это уже не сфера действия 1С. Но если так сказать - то вы ровно попадете в мою основную мысль.

(74) а классическое update where ? Не получится. Получится только - получая каждый объект. причем целиком - со всеми ТЧ. Каждый - по очереди. А запись будет происходить (не проверял, вангану) - сначала каждая тч будет очищаться через delete where, а потом записываться через insert. Объектная целостность - парадигма. Хорошая парадигма. Но в итоге получается запросы аж в двух циклах.

Интересно, а если ТЧ  у объекта пустая - платформа все равно делает delete?