07.08.2013, 20:30 | #1 |
Участник
|
Уникальность PartyIdIdx
Разбирал как система обращается с emplTable.PartyId
Нашел куски кода когда неявно предполагалась уникальность этого поля. Плюс есть метод findByPartyId на sys слое. Но индекс по этому полю неуникальный. Аналогичная ситуация с CustTable. А с VendTable еще веселее. Индекс был неуникальный а где то примерно с 8-го или с 7-го роллапа - уникальный. Коллеги, как же правильно обращаться с этим полем ? И если оно неуникальное, то зачем в коде в ряде мест с ним обращаются как с уникальным значением ? p.s. Ax 2009 |
|
08.08.2013, 09:56 | #2 |
Участник
|
Цитата:
Нашел куски кода когда неявно предполагалась уникальность этого поля
X++: if (!this.PartyId) { ret = ret && checkFailed(strfmt("@SYS122460")); } else if (!this.validateUniquePartyId()) { // The PartyId is already related to another employee in the same company. ret = ret && checkFailed(strfmt("@SYS123373", "@SYS36113", this.PartyId)); } X++: public boolean validateUniquePartyId() { boolean retValue = true; EmplTable emplTableLocal; ; select count(RecId) from emplTableLocal where emplTableLocal.PartyId == this.PartyId && emplTableLocal.EmplId != this.EmplId; if (emplTableLocal.RecId) { retValue = false; } return retValue; } 1) Физ. лица в компании должны быть сопоставлены с каталогом как один к одному 2) Поставщики, Клиенты возможно как многие к одному, ввиду необособленных подразделений или обособленных или холдингов и т.п. и т.д. Интересно узнать мнение тех кто глубоко в этом разбирался... P.S. Оправдать неуникальность индекса можно было бы только выводом более информативного сообщения, однако сообщение о не уникальности при такой проверке не будет, а вот при вставке записей кодом это может оказать "медвежью услугу" Последний раз редактировалось ansoft; 08.08.2013 в 10:09. |
|
|
За это сообщение автора поблагодарили: Logger (3). |