v7: ЗначениеВстрокуВнутр() - длина строки? #680062

Какая максимальная длина строки для ЗначениеСтрокиВнутр(НекийОбъектБазы)..?

Мне с Внутр 64 хватало. Без Внутр - не знаю.

Неограничено. Но при большом размере начинаются тормоза.

да, вот надо составной индекс в справочник запихнуть Документ+Контрагент . пихать индекс в Наитменование хочу, максимальная длиня = 100 - вот хватит для двух Внутр?

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

Так получи два внутренних кода объектов. Тип документа + вн.код документа + вн.код контрагента.

Загони в него ТЗ из мильёна строк.

а вн.код документа - разве однозначно не идентифицирует сам документ...? по идее можно без типа документа обойтись??

Не помню.

Может не стоит ЗначениеВСтрокуВнутр? Оно может неожиданно меняться. На сколько помнится. вернет одно значение. вернет другое значение третье. Точно не обещаю, но где-то так. Лучше на основе ЗначениеВСтрокуВнут генерировать какой-то свой уникальный идентификатор? Заодно и индекс компактней будет.

А кто мешает сделать Сообщить(ЗначениеВСтрокуВнутр(Док.ТЕКУЩИЙДОКУМЕНТ);? И зачем всё в строку гнать, если можно выцепить ID.

На сколько помнится, будет разница из-за того, является ли Док переменной документ определенного вида, или документ неопределенного вида или просто неопределенного типа. Разница в расположении внутреннего идентификатора вида в строковом представлении ЗначениеВСтрокуВнутр и еще в чем-то... точно не помню.

У меня в конфе используются такие функции (делал для себя, если кто будет использовать, я ни за что не ручаюсь):

Текущийдокумент  в любом случае возвращает одно и тоже. И вот ссылка на проверенный более чем десятилетием вариант.

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

Внимательней прочитай то что по ссылке. Там ровно тот-же код что и у тебя.

читаю...

Ты просто не использовал Текущийэлемент

ух, мозголомство какое... не понял навскидку есть, например, 1. реквизит документа, реквизит типа = "Документ.Реализация" 2. реквизит документа, реквизит типа = "Документ" . и в том, и в другом случае надо получить одинаковый ид для документа, хранящегося в реквизите ????

Дописать .текущийдокумент

т.е. просто желать так ТекДок = ВыбДок.РеквизитТипаДокумент;

ок. и со справочниками аналогично..? текущийЭлемент

Да.

Ну, суть в том, что ".ТекущийЭлемент", это, говоря восьмерочным языком, ".Ссылка". А собственно объект типа Документ.xxx - это как бы не сам документ, а менеджер документов..

Я знаю.

И? Для объекта глПользователь твой код вернул <     E>, шесть символов, без кода ИБ, без идентификатора типа/вида объекта. Моя функция для глПользователь  возвращает <U-E-ЦБ>. Тоже шесть символов, но гораздо больше информации внутри. К тому же, моя функция нечуствительна к тому, добавишь ли ты .ТекущийОбъект или нет. Меньше возможности случайно накосячить.

Я тебя не понимаю. В не нужен тип справочника, не нужен код УРБД. И кто тебе мешает написать сокрлп?

Эсли ты косячишь, то допиши

Или ты хочешь сказать, что ты умеешь дописать несколько символов к строке (тип справочника и код ИБ), так что длина не меняется? :)

при наличии ID гонять в строкуВнутр хуже чем лысого гонять.

Вид справочника не нужен, а вот про вид документа не понятно. Упомянут просто "документ" произвольного вида. И про наличие или отсутствие РБД ТС ничего не упоминал. Так что предложение идентификатора без вида документа и кода ИБ несколько некорректно. Я заменяю цепочку пробелов на разделители. Получается три разделителя (теряю три байта), но экономлю больше за счет исключения пробелов. Канонический идентификатор документа/справочника занимает двадцать три байта. А у меня, к примеру, внутренний идентификатор партии, полный, с видом объекта и кодом ИБ, укладывается в 11 байт. Не смотря на то, что количество элементов в справочнике партий около 900 тысяч.

Тебе с какой целью индекс? Насколько помнится отбор работать не будет для строки длиннее 23 символов :) Но в эту длину вполне можно впихнуть пару значений в виде ID

Всегда можно сделать ключ хеш-функцией.

На сколько помнится, в реквизит неопределенного типа можно запихать строковое значение не более 23 символов. А максимальная длина индексного значения, на сколько помнится, не более 112 символов.

лабаю альтернативную "ГП" - чтобы восстанавливать можно было не всю базу чохом, а по выбранному клиенту... соответственно в справочнике индекс Контрагент+ТекущийДокумент - этот индекс указывает на ГП для конкретного клиента.

блин, ны вы все понаписали... мне нужно всего-то реквизиты документа, которые могут иметь тип "Справочник.Контрагенты" или "Документ" положить в строку и все. независимо от того, какой будет вид реквизита "Документ" - все документы, или Документ.Конкретный . делаю сейчас просто: СтрДляКонтрагента=ЗначениеВСтрокуВнутр(ВыбКонтрагент.ТекущийЭлемент); СтрДляДокумента=ЗначениеВСтрокуВнутр(ВыбДокумент.ТекущийДокумент); . УРБД - нет, но для универсальности бы не помешало учитывать...

Ну поиск-то по этой строке делать будешь? Индекс с отбором? Тогда длина критична. Сейчас попробовал для первого попавшегося элемента справочника партий стандартное ЗначениеВСтрокуВнутр и свою функцию. Получил: {"B","0","0","214","0","0","    666660ЦБ "} 5Y-EAEC-ЦБ Для лучше для индекса, сам понимаешь, не неофит таки :) Или из ссылки в сделать нужное.

Отбор - пока не планируется...