27.01.2014, 15:00 | #1 |
Участник
|
ax2012: что за таблица SubLedgerJournalTransferNumberSeqTmp? почему содержит много данных?
ax2012
разбираюсь с этим *** subledger что за таблица SubLedgerJournalTransferNumberSeqTmp? почему содержит много данных? около 100К записей msdn утверждает, что эта таблица содержит временные данные ( table holds the subledger journal transfer temporary data) http://msdn.microsoft.com/en-us/libr...berseqtmp.aspx а почему тогда таблица регулярная? и где она должна очищаться? удаление записей есть только в методе \Classes\SubledgerJournalTransferCommand\createNumSeqTmpData но непохоже, чтобы этот метод выполнял массовую очистку может кто разбирался с этими **** субкнигами? |
|
|
За это сообщение автора поблагодарили: gl00mie (2). |
27.01.2014, 15:29 | #2 |
Участник
|
Судя по всему, она используется для того, чтобы генерировать номера журналов ГК ( \Classes\SubledgerJournalTransferCommand\generateJournalNumbers ) чтобы можно было потом их вставить одним insert_recordset ом (как, например, тут \Classes\SubledgerJournalTransferCommand\insertGeneralJournalEntryRelated).
По идее можно было бы использовать временную таблицу типа TempDB но почему-то так не сделали - надо выяснить. И похоже очищается она только перед генерацией новой порции - что довольно подозрительно. |
|
|
За это сообщение автора поблагодарили: gl00mie (2). |
27.01.2014, 15:33 | #3 |
Участник
|
|
|
27.01.2014, 16:29 | #4 |
Участник
|
По идее они должны создаваться вначале каждого переноса из субкниги в ГК и удаляться в конце. Но сейчас я вижу, что они создаются в отдельной транзакции.
Так как перенос может осуществляться в отдельном пакетном задании, в случае систематического сбоя, вероятно, он может генерировать там записи снова и снова. Сейчас таблица растет? Насколько последний transferID в этой таблице отличается от последнего transferID в \Data Dictionary\Tables\GeneralJournalEntry? |
|
27.01.2014, 16:36 | #5 |
Участник
|
Цитата:
Сообщение от belugin
Так как перенос может осуществляться в отдельном пакетном задании, в случае систематического сбоя, вероятно, он может генерировать там записи снова и снова. Сейчас таблица растет? Насколько последний transferID в этой таблице отличается от последнего transferID в \Data Dictionary\Tables\GeneralJournalEntry?
transferID - разные. для каждого в среднем по 100 записей. есть и группы по 2-3тыс. записей. правильно ли я понимаю, что записи остаются только в результате ошибки? я правильно понимаю, что таблицу можно просто очистить вручную sql-запросом? а то я что-то засомневался. |
|
28.01.2014, 09:39 | #6 |
Участник
|
Судя по перекрестным ссылкам это должно быть так. Причем исключения обработаны корректно - значит должен происходить какой-то сбой. но зуб не дам - надо спросить у коллег.
Если решишь чистить, учитывай статус (subledgerJournalEntry.Status == SubledgerJournalEntryStatus::Transferred) чтобы не потереть данные текущих транзакций Последний раз редактировалось belugin; 28.01.2014 в 09:43. |
|
|
За это сообщение автора поблагодарили: mazzy (5). |
28.01.2014, 10:04 | #7 |
Участник
|
максим, может подскажешь или выскажешь свои соображения...
а зачем этот "закат солнца вручную"? ведь есть нормальные номерные серии, на худой конец есть recid... зачем выделять и резервировать номера таким... хм... необычным способом? чего хотели добиться этой таблицей? |
|
28.01.2014, 10:08 | #8 |
Участник
|
Если внимательно присмотреться, то там создаются номера из номерных серий это просто вспомогательная таблица, чтобы можно было затем при создании записей присваивать их одним insert|update_recordset, а не создавать вручную позаписно - я подробнее постараюсь сегодня-завтра посмотреть.
|
|
28.01.2014, 10:22 | #9 |
Участник
|
|
|
29.01.2014, 09:06 | #10 |
Участник
|
Насколько я вижу, да - таблица используется только в коде переноса из субкниги в ГК (в классе SubledgerJournalTransferCommand и его расширения для корреспонденции - последнее, впрочем можно не рассматривать, так как концептуально там дублируется примерно тот же алгоритм, только с учетом группировки по парам проводок).
Сначала туда генерируются номера будущих GeneralJournalEntry, ( \Classes\SubledgerJournalTransferCommand\createNumSeqTmpData дл создания таблицы, \Classes\SubledgerJournalTransferCommand\generateJournalNumbers для присвоения номеров ) Затем вставляются сами Entry, используя номера оттуда ( \Classes\SubledgerJournalTransferCommand\insertGeneralJournalEntryRelated ) Затем она используется, чтобы привязать проводки к GeneralJournalEntry ( \Classes\SubledgerJournalTransferCommand\insertGeneralJournalAccountEntryRelated ) И в конце записи удаляются, а при исключении еще и возвращаются номера в номерную серию: ( конец \Classes\SubledgerJournalTransferCommand\executeTransfer ) Если так не делать, то вся вставка записей в ГК деградирует по быстродействию (придется использовать позаписную вставку, а не запросы к SQL серверу) |
|
|
За это сообщение автора поблагодарили: mazzy (5). |