|  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). | |