Включение потабличного RecID в 3-ке

[ZVV]

2 vc

ну да, где-то решение хорошее...
жалко вот только в случае этого конкретного клиента не выполняется второе условие

но зато уже знаю другого, кому это может пригодиться.

спасибо!

[Vladyslav]

Если грозит исчерпанием в будующем RecID можно воспользоваться следующим:
1) выделить наиболее прожорливые таблицы (обычно это какой-нибудь прожорливый протокол) в табличную коллекцию
2) колекцию в вируальную компанию
3) в виртуальную компанию включить вашу компанию (если компаний несколько, то создать для каждой по одной компании, или создавать для каждой таблицы... или выбирайте любую из допустимых комбинаций).

Для виртуальной компании генерится свой собственный RecId

Кстати, перекопав за долгие годы Аксапту вдоль и поперек, ни разу не встретил, чтобы RecId считалось где-то уникальным для всей системы (и сам такого никогда не писал, разумеется, и не давал так делать другим). Так что с этим проблем нет.
Механизм с виртуальными компаниями и коллекциями прекрасно работал в 3-ке. В 4-ке это оказалось уже не нужным - переимеовал значения в dataareaId обратно и удалил настройки компаний и коллекций (чтоб не вспомниать года через два зачем это нужно).

[ZVV]

Да, хорошее предложение - сам как-то не подумал про такой вариант...

[ZVV]

Владислав, а Вы не можете сказать, раз у Вас есть такой опят, как такое решение сказывается на производительности системы?
Если оно как-то сказывается?

PS Например если "выкинуть" таким образом InventTrans.

[Vladyslav]

Опыт есть, но не InventTrans
Как я уже упоминал: был заказ протоколировать всякую хрень, и объем этого протоколирования угрожал за впрочем довольно долгое время, но все же "съесть" весь ресурс идентификаторов записей.
Может если "выкинуть" подобное, то и для InventTrans хватит оставшихся двух миллиардов (это не считая отрицательных значений)?
Падения производительности не заметил (да и к чему бы). Будет ли падение при обращении к InventTrans? Вряд ли. Аксапта ведь в SQL запрос с объединением передает не как a.dataareaId = 'my1' and a.dataareaId = b.dataareaId, а как a.dataareaId = 'my1' and b.dataareaId = 'my1'
Нет, ну разумеется она там где-то внутри себя потратит время на "подстановку", но столь малой (надеюсь на это) величиной можно пренебречь

[ZVV]

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

Резюме: Пользуйтесь поиском, не изобретайте велики!

[Vladyslav]

Ну вот "наобещал" и сегодня же (впервые) нарвался на место, где 3-ка предполагает уникальность RecId в пределах всей базы: таблица SpecTrans
Поле RefId было заменено в четверке на RefTableId и RefRecId
Просто если пометить открытые проводки для сопоставления клиентские (CustTransOpen), то можно при наличии "своих" RecId в открытых проводках поставщика (VendTransOpen) доооолго размышлять, чего это она считает, что проводка еще где-то помечена.