Они там (разработчики) все сговорились что-ли? #547547

Вот типичная ситуация из модели данных: получаю я запросом такую таблицу Товар1,Всостоянии1,2 Товар2,Всостоянии1,3 Товар1,Всостоянии2,4 Товар2,Всостоянии2,5 После этого,я её смотрю в динамическом списке и разработчики платформы говорят: "твои записи неуникальны ни по одному полю, поэтому нельзя задавать в виде основной таблицы ни справочник товары ни справочник состояния, ибо отображаться будет криво". Я говорю ладно, у меня справочник товары огромен в сравнении с такими выборками, дай-ка я сделаю такую вещь: Товар7,Товар1,Всостоянии1,2 Товар8,Товар2,Всостоянии1,3 Товар9,Товар1,Всостоянии2,4 Товар10,Товар2,Всостоянии2,5 И скажу: вот основная таблица у меня поле № 1 справочникТовары1, а все остальное - вспомогательное. На форму поле 1 не вывожу, а данные группирую по "не основным", а как бы вспомогательным реквизитам и вижу то, чего мне надо. Во что упирается эта задача? В то, что надо связать две таблицы. Просто сшить их без всякого условия первый с первым, второй со вторым и тра-та-та. Если говорить на языке матриц - надо взять шпур. А они мне декартов квадрат (всю матрицу), да есть такие задачи, где надо cross join, и хорошо, что sql сервер какой-бы-он-ни-был cross join делать умеет. Но почему, блин, так сложно взять шпур? Или я не прав и все это сделать можно? Или разработчики sql-я давно уже сделали реализацию запрос-шпура, и только бравые разработчики 1С тормозят прогресс. Или те или другие или и те и другие никак не сделают чтобы удобно. Именно по этому задача о перенумерации все время решается через выбрать из того-же-самого. Где здесь ограничение платформы, почему не реализовать. Или чё?

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

Пойди документацию на дин. список почитай. Вдумчиво. Чтобы хоть немного понимать как он работает, что и в каком объеме из БД считывает. Может начнешь по назначению использовать, а не по хотению...

Ты считаешь, что ты больше состоялся как клоун, чем как специалист?

С мое по программируй сперва.

А, так это для тебя фирма 1С платформу пишет? Накосячили в реализации твоих спецификаций? Тоже мне, пупок...

Ааа жжете парни. Пишите ещЁ. Пишите, умоляююю, мне скучно

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

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

что-бы понять сколько лет вы програмиированием занимаетесь озвучитли-бы хотя-бы возраст и достижения... перефразируя одну армейскую пословицу: "Куда буха не целуй всюду задница!". Это к тому что не всегда нужно идлти у юзера на поводу. В данном случае точно нельзя!

Зря ты так. Автор четровски прав. Скажем так - проектировал он правильно. 1С делала тоже правильно. Неправильно, что эта особенность не описана здесь. Свойства: Методы: ПолучитьОбязательноеИспользование (GetRequiredUse) Описание: Динамический список предоставляет разработчику возможность описать в форме запрос практически произвольного вида, указать условное оформление данных, порядок сортировки, отборы и группировки данных. Ограничения: в запросах нельзя использовать объединения. Доступность: Тонкий клиент, веб-клиент, сервер, толстый клиент. ЧОрными буквами. Жирно. С подчеркиванием и воскл. знаком.

Позабавило: Ограничения: в запросах нельзя использовать объединения. Краткость, млять, сестра таланта... Ага..

Я, кстати, сам счаст проверил, что сказал аутор, узнал, осознал, удивился и запомнил на будущее.

Вот прямо отсюда: вот из первой же ссылки вот такой вот комментарий Проблема снимется, если перейти на 2005 И получается, что все давно все получили и ROW_NUMBER и аналоги в других sql-ях и только доблестные программисты платформы 1С ну никак не могут предложить такую функцию в запрос (ибо далее все просто join on ROW_NUMBER = ROW_NUMBER) и это в 2011 году. Абзац полный.

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

Как ты смееш упоминать ИТС?? Не стыдно, очередной впариватель навязанной услуги. Франч что ли?? ась??? ;)

я вас умоляю! Вам так хочется сделать нестандартное - флаг в руки! Только тогда про все стандатрные фичи забудте! делал я такое и отображение в 1 форме нескольких связанных таблиц одновременно, ещё на 7.7 делал, ничего архисложного, просто ручками-ручками а не конструкторами и втроеным функционалом платформы!

Я злой и страшный желтый франч! Горжусь этим и замышляю всякие гадости, ага.

рыбак рыбака?

А типа понять что я лох подзаборный оказывается проще и ничего доказывать не надо? С таким отношением к коллегам надо в правительстве работать а не 1С ом заниматься. По сабжу: среда разработки не должна обязывать пложить не нужные для учета сущности. Вот у меня на ИТС сейчас открыт именно этот раздел. И я вижу, что он может соединять остатки товара с таблицей товара и никакой кэш у него не порвался. Наплоди я такую сущность и обзови её ТварыВСостояниях у него эта таблица статическая и никуда не двигается изменяется лишь прицепленная часть. Вопрос для разработчиков стоит в том, чтобы поддерживать соответствие в актуальном состоянии, что они и сделали для такой тупой и не нужной мне таблицы и на сделали для построенного на сервере индекса записи в таблице. А они там все-равно соответствие строят и разницы в реализации нет никакой. Сделай они это и возможности отображения данных в динамических списков выросла БЫ в разы.

Понятно. Франчи позор 1С, не чего кроме как впаривать УПП и ИТС не умеют. В блакнотик записал. Далее притензий не имею.

Да причем тут сразу лох??? Че так сразу. Учится учится и ещЁ раз учитя, так завещал Володя. Верь в зовещания Володи и на тебя снизайдет просвещение во тме 1Сру

Может проблема чуть глубже?? Может гдето (в каком то режиме это нельзы вытащить, может это с ВебИнтерфейсом связано и с тонким клиентом???

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

, RowNumber в данном случае это костыль. Прямая реализация - это создание виртуального поля, составного уникального индекса в качестве основной таблицы.

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

-> :)

а вы не задумывались над тем, что динамический список предназначен для вывода одной таблицы, но с возможностью вывода дополнительных полей, а не для вывода данных, полученных сложным запросом?

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

Да, я по сути рассердился, что не сработает костыль, который можно сварганить из примитивов. Я даже и не мечтал о полной и правильной реализации этой функциональности. А что у нас есть для сложных запросов? Если делать интерактивные отчеты, то зачем мне формы.

вот именно, использовать отчеты и не лохматить прочие механизмы.

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

И вообще!!! ты пишешь "запрос сложный", а он ни разу не сложный, он просто множественный результат выдает. Если так и дальше будем жить, то 1С 9.0 будет писать "Здравствуй мир", а все остальное не сможет ибо платформа не рассчитана на такую мегафункциональность.

лохом вас только вы сами назвали. а я не телепат и не ваш биограф, мне ваши достижения не известны, понимаете разницу между "0" и "null"? не-а, по другому.

И вы априори считаете ... Ваш вариант "по другому"? Сложно? Интересно мнение.

неправда! Я вообще про челов редко что утверждаю. Процитируйте где я что утварждал.

это я на про 0 и null, понимаю, забавный сравнительный пример так сам люблю: "ложки конечно не крали, а вот чувство какое-то ...".

на 8.* такой фокус не поучится, на 8.* можно и по другому, другое дело, что сейчас скорее всего сделал-бы по другому, возможно без кучи таблиц на 1 форме... возможно каким-то боком привязал-бы СКД. Пока нет такой задачи - не замарачиваюсь, и так есть чем заняться

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

а если принудительно отсортировать по какому-то не выводимому полю, например минимальный код из тех нескольких номенклатур что строке?

Сделал бы статусы - колонками, плюс колонка общего итога по номенклатуре.

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

тогда ему вообще статусы не нужны. Просто на форме поле для выбора варианта расчета остатков, которое изменяет наложенный отбор.

Отбором все и кончилось. (биография, достижения) Постановка задачи здесь Решение здесь Эта тема относится к форме управления процессом.

ну и нах там решить а сюда с кривым и неполным описанием повторно постить?

: "Пока нет такой задачи - не замарачиваюсь" - на случай, если задача возникнет, а модель данных надо строить. Попробуй готовую, не понравится сделаешь свою. Под вопросом даже что первично задача или способ решения.

в >90% слукчаев даже такой косноязычный как я сам убеждает других что это им не надо...

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

отсыпь...

Очередной сказ про ежиков

Подумал я ещё раз на эту тему и увидел, что я даже не на то ругнулся, что нельзя взять в матрице след или шпур (что то же самое). А что можно, но извратно. Это тема как проставить номера. Два подзапроса, умножаются на два до номеров и два в результате склеиваются по полю номера и вся эта конструкция идет в динамический список. И все получится как хотелось, но очень мутрно. И упрек справедлив полностью. Отсутствие реализации RowNumber делает язык запросов 1С кривее, чем турецкая сабля.

а нафига она нужна? в СКД той же можно вполне себе вывести поля с нумерацией как в целом так и по группе...

Отображение динамического списка с группировкой.

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

потому что пацаны из 1С идут в ширину, а не в глубину. поддерживает 4 разных СУБД, и ни с одной из них нормально работать не может.

1,Товар1,Всостоянии1,2 2,Товар2,Всостоянии1,3 3,Товар1,Всостоянии2,4 4,Товар2,Всостоянии2,5 Я могу подзапросом соединяя то же с тем же проставить номера у таблицы 1 из , 1,Товар7 2,Товар8 3,Товар9 4,Товар10 вторым подзапросом я проставляю номера у основной таблицы динамического списка И соединяю два подзапроса по проставленным номерам. Вот и след. Получаю искомый запрос состоящий из 4-х подзапросов друг в друга попарно вложенных. Вместо одного прямого запроса с соединением по RowNumber.

блин, как мне стыдно! как стыдно! стоко пробелов в знаниях! Из ветки поняла только процентов 30 ...

Забей и не парься. Шашлычки на свежем воздухе куда лучше. Профессиональный рост - мотиватор для негров. У нас в универе говорили "Матан большой, чего-то да не знаешь". Ну и наоборот "Матан большой чего-нибудь да знаешь".

объединять запросы по rownumber это сильно... это да.. ну разработчики платформы, ну тууупыыееее...

бгг

поржал

стесняюсь спросить, а зачем RowNumber пригодился IRL? Чем индекс строки ТЧ плох?

как зачем? см

Ещё разик тему перечитай. Все разжевано. Объединять по RowNumber это костыль для отображения в динамическом списке набора данных, который ни в одном своем поле не имеет уникального ключа, уникальный ключ - набор полей (таблица 1 из ). Отображение такого набора данных в дин списке с установкой основной таблицы нужно для того, чтобы установить группировки динсписка. Без основной таблицы не будет группировок, а осн. таблицы не будет без уникального поля.

чисто уточнить - а разве уже запретили объединять по двум полям?? воистину говорят - нельзя лепить снеговика с клюшкой в голове...

Что ты имеешь ввиду? Запрос напиши для таблицы 1 из с объединением первых двух полей.

зачем их объединять?

Дурочку включил? Про снеговика это ты знаешь не понаслышке.

ответь на простой вопрос: зачем тебе задавать основную таблицу в твоем динамическом списке?

Чтобы сгруппировать вывод списка по полю 2 (Всостоянии1, Всостоянии2).

вопрос: внутренним соединением твою таблицу из к справочнику товаров если присобачить и назначить справочник товаров основной таблицей?

По первому полю? - сразу неуникальные значения и косяки в отображении дин.списка.

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

Можно этот элемент формы реализовывать как дерево значений, чтобы все было также (визуально). Однако, дерево значений не обновляется нормально, его надо обновлять принудительно. Поэтому во многих задачах отличных от "Хелло ворд" информация для просмотра и некоторых действий должна выводиться динамическим списком. И см. я могу её вывести, но на построение этого списка система (ШТАТНОЕ ПОСТРОЕНИЕ) затратит много ресурсов. В то время как есть _простое_ решение использовать RowNumber. Простое потому, что раз система может поддерживать в актуальном состоянии 4 подзапроса два раза друг в друга вложенных, значит нет там опоры на индексы сервера баз данных такой, которая сделала бы невозможной использование RowNumber. Это баг проектирования. Или косяк или ограничение, поставленное спецом, чтобы сделать использование динамического списка ограниченным вот-на-столько-вот. Это блин телега с двумя колесами по диагонали.

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

Поддерживаю. ФГМ-метр автора 0 [''''''/'] 9000

Это еще что. Мне тут рассказывали про одного увлеченного программиста, который жаловался, что в колонке табличного поля нельзя отобразить таблицу...

Будешь разработчиком конфигурации - будешь сам решать, где использовать ДС. Гляди, как бы в меньшинстве не оказаться.

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

Форумный троль (ФТ далее) - это человек который пишет на форумы оскорбления и копипасты. Целью ФТ является поднятие собственного ЧСВ в спорах использует риторику и демагогию.

Уважаемый детектор! Принимая во внимание оскорбления , , , а также цитаты , - прошу вас детектировать себя по определению ФТ. Далее, вдумчиво читая , - рекомендую вам курс лечения в ближайшем санатории.

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