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

[sparur]

Здравствуй Коллективный Разум.

И снова требуется твоя помощь.
Столкнулся с совершенно аномальной для меня ситуацией при работе со строками закупок (purchLine). Ничего не остается как спросить объяснения у всезнающих гуру.

Вообщем , ситуация следующая:

есть строка в закупке, пытаюсь найти на нее ссылку в табличном методе delete таблицы MarkupTrans по ее recId хранящейся в поле transRecId. Никак не получается этот фокус у меня. В ходе танцев с бубном выяснилось следующее:

имеем запрос вида:
select firstonly purchLine where purchLine.RecId == -1116895965;
где цифры это собственно сам recId строки закупки и есть

либо можно использовать стандартный метод на таблицы purchLine под названием findRecId, куда передать эту же циффру.

пытаемся использовать этот запрос в 2-х случаях:
1) в табличном методе markupTrans'a
результат - ничего не найдено
2) в отдельном Job'e
результат ЕСТЬ!!! однако несколько странный, а именно:
смотрим в отладчике и имеем после выполнения select'a запись в purchLine находится, НО в окне просмотра переменных recId отображается СОВСЕМ другой в угловых скобках, точнее так: purchLine: <3178071331>
далее если раскрыть переменную то увидим список всех полей, идем на recID b видим цифру, переданную в качестве параметра в запрос, т.е. -1116895965.
Как такое возможно?
плюс ко всему если в обозревателе таблицы поискать запись по recId, то по обоим этим цифрам (3178071331 и -1116895965) мы попадаем на одну запись.

Кто может объяснить сие явление буду очень благодарен! Интерес вызывает как сама ситуация с 2-мя recId, так и вопрос почему запрос отрабатывает по-разному в разных ситуациях (см. выше)

Получилось длинно, зато надеюся информативно

[EVGL]

Отрицательные RecId: http://axforum.info/forums/showthread.php?t=6211

[sparur]

Цитата:

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

Отрицательные RecId: http://axforum.info/forums/showthread.php?t=6211

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

в моем примере это job и табличный метод! почему в джобе находится запись а в методе таблицы НЕТ ???

[oip]

3178071331+1116895965=2^32

[EVGL]

Зачем задавать философские вопросы? Читайте и решайте проблему.

[sparur]

Цитата:

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

3178071331+1116895965=2^32

это уже понял, непонятна двоякая ситуация с различной отработкой одного и того же запроса

[AndyD]

2 oip
Я бы сказал так
1116895965 == ~((unsigned int)3178071331) + 1;
3178071331 + ~((unsigned int)3178071331) = 2^32-1;
а в общем
(int)-1116895965 == (unsigned int)3178071331

2 sparur
У меня такой код отрабатывает нормально

    PurchLine   purchLine;
    ;
    purchLine = purchLine::findRecId(-1116895965);

Запись находится. Или у вас только в Delete() не отрабатывает?

[sparur]

Цитата:

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

2 oip
Я бы сказал так
1116895965 == ~((unsigned int)3178071331) + 1;
3178071331 + ~((unsigned int)3178071331) = 2^32-1;
а в общем
(int)-1116895965 == (unsigned int)3178071331

2 sparur
У меня такой код отрабатывает нормально

    PurchLine   purchLine;
    ;
    purchLine = purchLine::findRecId(-1116895965);

Запись находится. Или у вас только в Delete() не отрабатывает?

в этом то весь и геморой!!! если этот код написать например в отдельном JOb'e , то все находится. А вот в табличном методе delete() на markupTrans'e не хочет искать!!!
пытаюсь как то преобразовать отрицательный рекИд ничего пока не выходит

[AndyD]

А не могли бы вы привести код в этом методе?

[sparur]

Цитата:

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

А не могли бы вы привести код в этом методе?

пожалуйста мне не жалко :

public void delete()
{
    TGP_SyncUz2Buh  sync;
    MarkupTrans     markupTrans;
    Common          refTable;
    PurchLine       purchLine;
    
    super();

    //ищем запись таблицы, для которой создается строка накл. расходов
        switch (this.TransTableId)
        {
            ......
            case tablenum(PurchLine):
                refTable = PurchLine::findRecId(this.TransRecId);
                
            break;
            ....
        }
        ....
}

this.TransRecId - это и есть этот минусовый recid

[sparur]

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

[sparur]

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

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

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

[EVGL]

Нет никакой дилеммы. Запускайте дефрагментрование RecId.

[sparur]

Цитата:

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

Нет никакой дилеммы. Запускайте дефрагментрование RecId.

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

[EVGL]

Вот уже жертвы рекламы пошли. Используйте штатную процедуру проверки RecId. Сидит совершенно бесплатно в форме SQL Administration и исправно работает.

[sparur]

Цитата:

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

Вот уже жертвы рекламы пошли. Используйте штатную процедуру проверки RecId. Сидит совершенно бесплатно в форме SQL Administration и исправно работает.

у меня таблица MarkupTrans, где TransRecId имеет EDT RecId, а не RefRecId.

Запуск данной процедуры не убьет ли мне ВСЕ ссылки в принципе?

[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 с ними не работает) - выше преобразование некорректно.

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

[mazzy]

Цитата:

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

Вот уже жертвы рекламы пошли. Используйте штатную процедуру проверки RecId. Сидит совершенно бесплатно в форме SQL Administration и исправно работает.

Вот они - спокойные пользователи международного функционала.
Где тип полей со ссылками на recId унаследованы от типа refRecId...

[mazzy]

Цитата:

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

Запуск данной процедуры не убьет ли мне ВСЕ ссылки в принципе?

ВСЕ - не убьет.
Убьет только те ссылки, которые находятся в полях с типом, не унаследованнsм от recRefId.