Как в реквизите документа хранить список значений? (v 8.1) #557963

Как в реквизите документа хранить список значений?

таб часть сделай

не катит, нужно реквизит

Хранилище значений

Через точку с запятой, либо какой-то другой спецсимвол. Встречный вопрос: а зачем?

Затем, чтобы можно было указать в Инвентаризации несколько контрагентов

Как можно хранилище значений здесь заюзать*

Типовой документ? Переделывать под ТЧ неохота?

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

Только ТЧ

через хранилище все хранится. Или через ЗначениеВСтрокуВнутр и ЗначениеИзСтрокиВнутр

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

Почему нет желания?

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

делаешь реквизит, тип - ХранилищеЗначений

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

а зачем ссылочная целостность для справочных данных??

Если взять тип значения реквизита ЛюбаяСсылка, то не прокатит?

Дык, ТЧ как раз для того и придумана, чтобы хранить список значений.

Удалили элемент справочника Контрагенты, ссылка на который присутствовала в этом списке. И что? В результате имеем битую ссылку в документе.

Дествительно. Глупостей какихто наговорили...

ставишь при чтении проверку на "существует контрагент? - ДаНет"

Кстати, всегда удивлялся 1С-у после SQL Server-а. Можно (если хватит прав, конечно) удалить элемент справочника, на который есть ссылки... SQL Server такое в жизни бы не позволил.

Нет. Ну ломает его отдельная табличка в базе. Хотяя, я его понимаю. Автор, прикрути отдельный регистр сведений. Пусть твой последователь ококует, когда увидит зоопарк ТЧ и отдельно регистр. Удивляй!

ну если нельзя хранить в "суперской среде разработки" список - то куда деваться? ))

Это если foreign key. Но они - тормознутые (говорят).

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

пупер )) >>"ну если нельзя хранить в "суперской среде разработки" список - то куда деваться?

Писец. Рекомендую почитать книгу "Практическое пособие разработчика 1С" и посмотреть на SQL вариант 1С базы данных и узнать про структуру таблиц.

а что за конфа? секретная разработка? ))

>> ну если нельзя.... Ну конечно надо выбрать самое дебильное решение совершенно не гарантирующее целостность данных. Это же очевидно! Особенно, когда задача решается одной элементарной табличной частью.

и давно вы напрямую в SQL из 8-ки пишете? )

Ну зато уж точно ничего лишнего не удалишь. Помнится писали для SQL Server 7 хранимую процедурку, которой даешь ссылку, она удаляет все связанные записи (и все записи, связанные со связанными записями и т.д. рекурсивно), а потом удаляет указанную запись.

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

именно что нужен объект "Список", а не ТЧ. А делать попу через две других попы - для 1С это нормальное состояние ))

так если у вас там ТЧ даже на склады есть - почему нет отдельного регистра сведений под это дело?

Как бы вы сделали, будь на месте 1С?

На склады нет ТЧ, есть уже других 5 штук, если сделать контрагнетов, организации и склады, то будет 8 ТЧ

хранить списки как набор значений... а как еще? )

Не обращая внимания. Он чиста так - потроллить. Всё равно толкового решения не родит, но какашками 1С закидает.

так сделайте одну на все три измерения ))

Отдельный регистр

Вот он истый дятлоизм.

Физически, с т.з. SQL - как?

да уж, куда толковее: чуть что - делать виртуальную ТЧ и держать её в уме. "Делать по-уму и правильно изгаляться - разные состояния". Можете цитировать ))

Все еще упорствуешь?

лучше 8 ТЧ чем список в реквизите. это вообще бред полный

Думаю может использовать СохранитьЗначение и Восстановитьзначение, хотя это тоже самое, что и использовать ХранилищеЗначения

сделать одну таблицу под данные "Список" и писать новое значение списка в новое поле "ИндексN". Нет?

как потом запросом документ получить по нужному контрагенту?

При добавлении нового значения новая колонка в таблице появляется?

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

как потом запросом документ получить по нужному контрагенту? - согласен, не подойдет СохранитьЗначение

как потом запросом документ получить по нужному контрагенту? - можно поподробнее?

А что (по-вашему) подойдет?

вы уже потеряли нюх с этой 1С )) вот:   Контрагент     Организации     Склады 1 2 3 4 5 ... n - пишите списки по 3-м измерениям любой протяженности в одну ТЧ ))

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

>>реквизит шапки, чтобы в него писать представление табличной части, если нужно видеть его в списке документов - это как? вы в представлении ТЧ будете перечислять содержимое всего списка?

Смотри как в ЗиУПе сделано в кадровых документах, реквизит "Состав"

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

Это как минимум 4 поля отводить под кластерный индекс для ключа и докуа полей под данные (если хотим контроллировать их целостность), либо одно поле под хранилище (image) если на целостность пофиг. Накуа?

ТЧ Вася Петя Коля Реквизит шапки "Вася, Петя, Коля"

по-моему, это уже попа через три попы... прогресс, однако... ))

Почему нет?

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

Представляю уже инновационный подход к программированию в 1с - конфа на регистрах сведений! Документ и справочник не нужны - берем два регистра сведений под шапку и табличную часть. Полный контроль.

Это удобство.

Нет. Тип данного - не строка, а число

а списки складов, контрагентов, Васей и организаций в одном документе - это тогда как назвать? ))

Криволобая постановка задачи скорее всего

в объективности вам не откажешь ))

шапка - где? ТЧ - в чем? Документ же отменили ))

Криволобая постановка задачи скорее всего - Скорее всего ты не значешь зачем они нужны.

а остальные типы в 1С разве не так? ))

Так чем вариант не катит? Всего 1 тч на сколько хочешь доп реквизитов без избыточности

Что значит остальные типы?

потому что представление показать - это одно, а данные сначала пихать в представление, потом показывать, потом обратно разбирать и получить одно нужное значение - это прогресс из :)

любой тип данных сложнее примитивного в 1С: >>Это как минимум 4 поля отводить под кластерный индекс для ключа и докуа полей под данные

Ты не понял - подход подразумевает, что новатор нарисует форму, которая подтянет данные из регистров сведений. Документ готов.

Amra 58 - 04.07.11 - 12:35 Смотри как в ЗиУПе сделано в кадровых документах, реквизит "Состав" Не увидел в приеме на рабоут реквизита состав. Где можно посмотреть? В каком конкретном доке?

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

Еще раз. Медленно. Что тебе непонятно с типами?

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

мне-то все понятно, я предлагаю вести еще один - список называется ))

аргумент в убил

Как ты его будешь хранить в базе данных?

Дружище, не пытайся что-то объяснить г-ну Лагранжу, тем паче не пытайся понять его. Это программа-бот. Она думать не умеет.

По теме - ответ в . БЕЗ вариантов.

ну если поп-классика не устраивает - то да )) ну хочет человек списать результаты на того, кто "потянет" )) а заранее не знает, кто.... как и остальные - записью

как и остальные - записью В какой таблице?

сложно организовать отдельную таблицу?

Конечно будет) Вообще речь про то что не нужно изобретать велосипеды, подменяя те средства, которые есть в платформе.

Отдельную таблицу для конкретного документа, либо отдельную таблицу для всех всех документов (типа глобальный общий список) ?

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

отдельную таблицу под тип данных "Список" значения списка - пишутся в поля. Переменной присваивается уникальный ссылка (как любят в 1С).

Структуру такой таблицы рассказать сможете?

нет, не буду. как-то не интересно ковырять "представления" 1С о "правильной" структуре базы, каковая потом тормозит при поиске и периодически вываливается с ошибкой SDBL. Сколько надо, столько пусть и пишут полей - индексы, ссылки, что там еще они считают "новаторским" - в результате все равно это будет работать как и все остальное.

Типичный подход дятла.

Сто!