13.01.2011, 14:25 | #21 |
Участник
|
Не самое лучшее решение...
А вы предлагали альтернативные варианты руководству ? Чем не устраивает хранение истории обработанных счетов на оплату например ? Там есть вся необходимая информация по истории заказа. Не удаляя строки заказов вы неизбежно будете получать тормоза. Со временем будет только хуже. |
|
13.01.2011, 14:27 | #22 |
Участник
|
Цитата:
Сообщение от AvrDen
При анализе нашли, что больше тормоза происходят в методе salesLine.lowestSalesStatus, который вызываеться из salesTable.updateBackStatus. Скорее всего из-за того что нет индекса по SalesId,SalesStatus в таблице salesLine. В итоге получается что при обработке заказа больше 1000 строк на обработку одной строки уходит порядка 10 сек.
|
|
13.01.2011, 14:28 | #23 |
Участник
|
|
|
13.01.2011, 15:01 | #24 |
северный Будда
|
У вас какие-нибудь отчёты строятся по строкам заказов? Если да, то какие?
__________________
С уважением, Вячеслав |
|
14.01.2011, 06:01 | #25 |
Участник
|
Нет, отчетов по строкам заказов нет. Но пользователи изначально работают с формой Заказы, она содержит много модификаций для удобства восприятия информации. И если предложить работать с формой накладных, то у них возникнет дискомфорт в работе. Пользователи сильно противяться этому.
|
|
14.01.2011, 11:09 | #26 |
Участник
|
Изменили код Classes\SalesFormLetter\postUpdate
X++: protected void postUpdate() { SalesParmTable localSalesParmTable; ParmId parmIdPrev; SalesId salesIdPrev; ; ttsbegin; localSalesParmTable = this.setForUpdateSalesParmTable(); localSalesParmTable.StartDateTime = startDateTimeTable; localSalesParmTable.EndDateTime = DateTimeUtil::newDateTime(systemdateget(),timenow(),DateTimeUtil::getUserPreferredTimeZone()); localSalesParmTable.updateParmJobStatusExecuted(); salesParmLine.clear(); // Sales totals are nulled in order to force a recalculation of the sales totals // which are then stored in the SalesTable.estimate field for utilization during credit limit check salesTotals = null; recordListSalesParmLine.first(salesParmLine); while (salesParmLine) { if (salesParmLine.OrigSalesId != salesIdPrev || salesParmLine.ParmId != parmIdPrev) { //counting number of SalesOrders we deal with if (salesParmLine.OrigSalesId != salesIdPrev) { ++numberOfRecords; } // 13.01.2011 AVRDV --> /* salesTable = salesParmLine.salesTable(true); if (salesTable) { salesTable.updateDocumentStatus(this.documentStatus()); salesTable.updateBackStatus(); this.updateSalesType(); this.createBackorderLines(); salesTable.updateDeadline(salesParmUpdate.RespiteDate); if (salesTable.SalesId != salesParmTable.SalesId) { // If this is not the primary sales order in the summary order, // void the credit card preauthorization that may exist as it is no longer valid this.voidCreditCardPreauthorize(); } } */ // 13.01.2011 AVRDV <-- localSalesParmTable = salesParmLine.salesParmTable(true); if (localSalesParmTable) { localSalesParmTable.updateParmJobStatusExecuted(); } } salesIdPrev = salesParmLine.OrigSalesId; parmIdPrev = salesParmLine.ParmId; if (!recordListSalesParmLine.next(salesParmLine)) break; } // 13.01.2011 AVRDV --> salesTable = SalesTable::find(salesIdPrev,true); if (salesTable) { salesTable.updateDocumentStatus(this.documentStatus()); salesTable.updateBackStatus(); this.updateSalesType(); this.createBackorderLines(); salesTable.updateDeadline(salesParmUpdate.RespiteDate); if (salesTable.SalesId != salesParmTable.SalesId) { // If this is not the primary sales order in the summary order, // void the credit card preauthorization that may exist as it is no longer valid this.voidCreditCardPreauthorize(); } } // 13.01.2011 AVRDV <-- ttscommit; } |
|
14.01.2011, 12:25 | #27 |
Участник
|
а если процессы изменятся?
|
|
14.01.2011, 13:05 | #28 |
Участник
|
какие процессы?
|
|
14.01.2011, 13:09 | #29 |
Участник
|
|
|
14.01.2011, 13:11 | #30 |
Участник
|
А почему в случае изменения процессов Вас беспокоит только эта модификация, а не 10 тысяч других, сделанных ранее?
Ясно же, что если меняются процессы, то много чего нужно пересматривать и проверять будет. Заложиться заранее на то, что именно и как изменится - невозможно. А конкретная проблема есть уже сейчас, и решать её нужно, и весьма эффективное решение найдено. Искренне поддерживаю автора. |
|
|
За это сообщение автора поблагодарили: AvrDen (1). |
14.01.2011, 13:51 | #31 |
Участник
|
|
|
17.01.2011, 14:29 | #32 |
Участник
|
Цитата:
Необходимо сохранить salesIdPrev, например в SET (он автоматически отбросит дубли в момент записи), а потом сканировать полученный SET, чтобы перебрать все SalesId. X++: Set setSalesId = new Set(types::String); SetIterator si; ; // Перебор salesParmLine recordListSalesParmLine.first(salesParmLine); while (salesParmLine) { (...) salesIdPrev = salesParmLine.OrigSalesId; setSalesId.add(salesIdPrev); (...) } // while (salesParmLine) // Перебор salesTable на которые есть ссылка в salesParmLine si = new SetIterator(setSalesId) while (si.more()) { salesIdPrev = si.value(); salesTable = SalesTable::find(salesIdPrev, true) (...) si.next(); } // while (si.more()) (...) |
|
Теги |
как правильно |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|