Два RecId у одной записи таблицы

[sparur]

об этом же кстати писал и Mazzy создавая тему, ссылку на которую Вы приводили в своем первом посте в данной теме!

Поможет ли стандартная дефрагментация? вот в чем вопрос... и не поубиваются ли у нас ссылки если EDT-recId (как минимум markuptrans, сопоставления...)

[AndyD]

Цитата:

Сообщение от sparur

сделал преобразование минусового recid (2^32-abs(recId)) получили положительный recId. который если подставить в фильтр в обозревателе таблицы позиционируется на записи с минусовым recid!

Однако в запросах не отрабатывает такое преобразование нигде!!! ни в Job'e, ни в табл. методе. Минусовый хоть в Job'e работает...

Вообщем дилемма, как разрешать - загадка.

Не совсем понимаю смысл этих преобразований. В любом случае в вашей переменной что знаковое, что беззнаковое значение хранятся как один и то-же набор битов (т.е. 0xBD6D8523). Различие лишь в его интрепретации (кстати, можете попробовать подставить шестнадцитиричное значение в вызове). Axapta оперирует лишь знаковыми целыми, по-этому вы всегда получите отрицательное значение для него.
Еще, 2^32 это уже 64-битное число (3.0 с ними не работает) - выше преобразование некорректно.

По существу - попробовал добавить этот метод - запись нормально находится

[sparur]

Цитата:

Сообщение от AndyD

...
По существу - попробовал добавить этот метод - запись нормально находится

Да, как оказалось проблема несколько в другом (если это можно назвать проблемой)

у нас ситуация была в следующем:
при удалении накл. расходов мне нужна была ссылка на "владельца" этих расходов, ее я пытался найти в табличном методе delete таблицы markupTrans. Это корректно срабатывает если удалять непосредственно накладные расходы (из формы накл. расходов). Однако, при попытки удалить скажем закупку естесственно система ДОЛЖНА удалять все. что связано с этой закупкой, в принципе все реализовано. НО реализовано так, что удаление накладных расходов, связанных с этой закупкой реализовано "каскадно"(см раздел DeleteActions на таблице PurchTable), то есть уже ПОСЛЕ удаления самой закупки, в итоге я ничего и не мог найти, т.к. запись уже была физически удалена.
Конечно, наверное стоит извиниться за поднятый сыр бор... однако узнал много нового и полезного

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

P.S. осталось найти другой вариант решения первоначальной задачи , но это уже завтра.

[glibs]

Вы уверены?

Предположим, средний размер записи с учетом индексов 400 байт.

4 294 967 296 * 400 = 1 717 986 918 400

т.е. свыше полутора терабайт.

В принципе, цифра теоретически достижимая. Но на практике кто-то видел базу на Аксапте, которая приближалась бы к таким размерам (да еще и при разумном подходе к ее администрированию ( http://axapta.mazzy.ru/lib/dbgrowthsolution/ ))?

[sparur]

Цитата:

Сообщение от glibs

Вы уверены?

Предположим, средний размер записи с учетом индексов 400 байт.

4 294 967 296 * 400 = 1 717 986 918 400

т.е. свыше полутора терабайт.

В принципе, цифра теоретически достижимая. Но на практике кто-то видел базу на Аксапте, которая приближалась бы к таким размерам (да еще и при разумном подходе к ее администрированию ( http://axapta.mazzy.ru/lib/dbgrowthsolution/ ))?

кхм, ну возможно Вы и правы ладно оставим вопрос риторическим

тема закрыта, всем спасибо за участие и понимание

[AndyD]

RecId не может превысить 2^32-1 (0xFFFFFFFF) - это максимальное число, которое может быть в нем сохранено. А это число, собственно, -1 в знаковом целом. Т.е. все пойдет опять по кругу. 1, 2, 3 и т.д.

Кстати, насчет дырок. Одна из причин их появления - каждый AOS (а так же тольстый клиент и клиент в 2-х звенке) резервирует под себя определенное кол-во recId (для уменьшения обращений к б/д при добавлении новых записей). При его перезагрузке это резервирование сбрасывается и выбирается новый диапазон при загрузке.

Да и на счет количества recId - у вас ведь остался 1 млрд. из 4-х (если не ручками вбивали). Сильно подозреваю, что размер б/д у вас куда меньше 1 терабайта. Так что, скорее всего, дырки у вас довольно большие (либо начинали работать при большом начальном номере recId). По хорошему, надо бы анализировать причину их появления

[sparur]

да, Вы правы наша база далека от такого объема будем работать в этом направлении

[TasmanianDevil]

AndyD, sparur - про временные таблицы или переведенные во временную ипостась экземпляры физических таблиц, жрущие RecId, не забыли ?
Часто пользуем - имеем большую частоту сброса счетчика RecId.

Не совсем по теме, но все же, хотелось бы узнать пару вещей :
1) Как ведет себя система, когда после N-ого сброса счетчика RecId в некой таблице будет попытка вставки записи с уже имеющимся в данной таблице/компании RecId ? Начнет перебирать дальше до нахождения непересекающейся величины или просто встанет с ошибкой ?
2) Каков сакраментальный смысл генерации RecId размазыванием счетчика по всем таблицам в рамках компании ?

[AndyD]

Вот насчет временных таблиц - можно поподробнее. Потому как я не заметил, что бы они что-то "жрали".
Нумерация для каждой временной таблицы (в том числе и тех, которые сделаны временными через вызов setTmp()) начинается с константы и возрастает на некоторую дельту (0x30) в рамках времени жизни табличной переменной. Если, к примеру, создать одновременной две одинаковые табличные переменные и вставить в каждую из них записи, то RecId у них будет одинаковый в соответствующих строках

Проверял на 3.0 sp3 cu1, sp5 fp2 c rollup 2 и без него.

[TasmanianDevil]

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

Спасибо, AndyD !

Одной головной болью стало меньше ...

[Recoilme]

Помимо временных таблиц есть ещё псевдовременные. Которые очень даже едят recid большими ложками. Тот же rectrans или reqpo например.
Надеюсь что одной головной болью не станет больше))

[glibs]

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

[Recoilme]

Согласен, но дело в том что на реальной БД дырки 100% будут..
По поводу дефрагментации - мне кажется лучше и эффективней кастрация, заодно и производительность поднимется, но не будем об этом)

[glibs]

Это один из способов. Я тоже про него писал выше.

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

Еще можно перевнедрение устраивать с реинжинирингом. Полезная вещь. Хотя и болезненная.