29.10.2008, 13:33 | #21 |
----------------
|
Миш, странно... по общему месту работы помню, что нельзя было в одной сессии отлаживать разноску документа, а во второй смотреть за обновлением данных.
|
|
29.10.2008, 13:38 | #22 |
Участник
|
2 Wamr
Так это для блокировки изменяемых данных сделано. Т.е. прочитать в другой транзации можно и изменений там не будет видно, но при попытке проапдейтить будет блокировка.
__________________
Axapta v.3.0 sp5 kr2 |
|
29.10.2008, 13:40 | #23 |
----------------
|
AndyD, извини, не понял мысль... о чем речь?
|
|
29.10.2008, 13:42 | #24 |
Участник
|
По поводу Oracle, возможно, в одной транзакции смотрели?
__________________
Axapta v.3.0 sp5 kr2 |
|
29.10.2008, 13:43 | #25 |
Участник
|
Цитата:
В этом контексте совершенно не понятно зачем в find методы понапихали selectLocked(!_update)
__________________
Axapta v.3.0 sp5 kr2 |
|
29.10.2008, 13:43 | #26 |
Участник
|
Цитата:
Как я делаю. 1) Создал таблицу Table1 2) Создал string поле Field1 3) Забил строчку с "1" 4) Запускаю job X++: static void Job21(Args _args) { Table1 t; ; ttsbegin; while select forupdate t { t.Field1 = "3"; t.update(); } while select forupdate t { t.Field1 = "4"; t.update(); } ttscommit; }
__________________
Энергия молодых и неравнодушных способна изменить мир к лучшему. |
|
29.10.2008, 13:44 | #27 |
Участник
|
Ну да, я правильно подумал
Вы откройте другую пользовательскую сессию и смотрите в ней.
__________________
Axapta v.3.0 sp5 kr2 |
|
29.10.2008, 13:47 | #28 |
----------------
|
это вряд ли. Открывал 2 Аксапты, в одной в дебагере по шагам выпонял разноску, а во второй смотрел как меняются статусы, аналитики, создаются проводки и т.д. и т.п.
так вот они не менялись пока обработка не заканчивалась Последний раз редактировалось Wamr; 29.10.2008 в 13:49. |
|
29.10.2008, 13:50 | #29 |
Участник
|
Цитата:
Вы первый уточнили что речь идёт о параллельной работе. Автор то темы в одной сессии делает.
__________________
Энергия молодых и неравнодушных способна изменить мир к лучшему. |
|
29.10.2008, 13:54 | #30 |
Участник
|
Ну, от исходного вопроса уже в сторону ушли
__________________
Axapta v.3.0 sp5 kr2 |
|
29.10.2008, 14:25 | #31 |
----------------
|
Цитата:
readers are not blocked behind writers and selecting with NOLOCK is no longer necessary
Цитата:
В этом контексте совершенно не понятно зачем в find методы понапихали selectLocked(!_update)
Цитата:
Так это для блокировки изменяемых данных сделано.
Т.е. прочитать в другой транзации можно и изменений там не будет видно, но при попытке проапдейтить будет блокировка |
|
29.10.2008, 15:00 | #32 |
MCITP
|
Ну вот отойди на минутку, так унесёт в такие дали.
Исходный вопрос был про ту же самую сесиию и транзакцию В той же сессии (и транзакции) где вы произвели изменение, но ещё его не зафиксировали (Commit), ваше изменение всегда будет видно. И не важно сиквел это или оракл! А вот в разных сессиях действительно для сиквела на тройке имел весто тот факт, что изменяя данные в одной сессии и не фиксируя транзакцию можно было увидеть уже эти изменения в другой сессии! (из-за использования NOLOCK вне транзакций). Однако если бы вы эти изменённые но незафиксированные записи в другой сессии попытались ещё раз изменить, то ни фига не получится, т.к. эти данные являются заблокированными и вы повисните в блокировке. На оракле такого быть не может по определению.. А на АХ4+2005 это уже вылечили, как отмечено выше...
__________________
Zhirenkov Vitaly |
|
29.10.2008, 15:09 | #33 |
MCITP
|
Цитата:
В Аксапте скажем так всегда "должны быть видны, но иногда бывают баги когда не видны" См. выше про глюк с InventTrans.
__________________
Zhirenkov Vitaly |
|
29.10.2008, 17:28 | #34 |
Участник
|
2 Wamr
На 2005 версионность может быть отключена (что и сделано по умолчанию). И с 2000-м Ax 4 разве не работает?
__________________
Axapta v.3.0 sp5 kr2 |
|
30.10.2008, 20:09 | #35 |
----------------
|
AndyD,
учитывая, что connection поумолчанию ReadComited это нежизнеспособные комбинации |
|
11.11.2008, 06:43 | #36 |
Участник
|
Почему отрабатывает без ошибок но накладную не разносит? ((
X++: select * from purchTable join purchLine where purchTable.PurchId == rDeferralsJournalTrans.PurchId && (purchLine.PurchId == rDeferralsJournalTrans.PurchId); purchLine = PurchLine::findRecId(purchLine.RecId,true); purchLine.PurchReceivedNow = rDeferralsJournalTrans.Qty; purchLine.InventReceivedNow = rDeferralsJournalTrans.Qty; purchLine.Dimension = rDeferralsJournalTrans.Dimension; purchLine.update(); purchFormLetter = PurchFormLetter::construct(DocumentStatus::Invoice); purchFormLetter.createParmLine(purchLine); ttsbegin; select forupdate * from purchParmLine where purchParmLine.OrigPurchId==rDeferralsJournalTrans.PurchId && purchParmLine.ParmId==purchFormLetter.parmId(); purchParmLine.LineAmount=rDeferralsJournalTrans.AmountCur; purchParmLine.update(); ttscommit; purchFormLetter.update(purchTable, rDeferralsJournalTrans.DocumentNum, systemDateGet(), PurchUpdate::ReceiveNow, AccountOrder::None, NoYes::No, NoYes::No);
__________________
Лучше сделать и жалеть, чем жалеть что не сделал |
|
11.11.2008, 10:19 | #37 |
Участник
|
Уже как только не пробовал, подскажите что и как можно сделать??
__________________
Лучше сделать и жалеть, чем жалеть что не сделал |
|
11.11.2008, 10:48 | #38 |
MCITP
|
А подебагить?
Вопросов по коду конечно много, но если по существу, то вы могли бы глянуть код метода purchFormLetter.update() и увидеть, что при его вызове чистятся "параметровые таблицы", которые были заданы ранее (см. вызов initLinesQuery()). И поэтому эти телодвижения над PurchParmLine перед вызовом purchFormLetter.update будут благополучно удалены.
__________________
Zhirenkov Vitaly |
|
11.11.2008, 10:49 | #39 |
MCITP
|
О том как в этом случае делать я приводил ссылку в самом начале этого же топика.
Разноска накладной
__________________
Zhirenkov Vitaly |
|
11.11.2008, 10:52 | #40 |
Участник
|
Цитата:
Сообщение от ZVV
А подебагить?
Вопросов по коду конечно много, но если по существу, то вы могли бы глянуть код метода purchFormLetter.update() и увидеть, что при его вызове чистятся "параметровые таблицы", которые были заданы ранее (см. вызов initLinesQuery()). И поэтому эти телодвижения над PurchParmLine перед вызовом purchFormLetter.update будут благополучно удалены. че то я туплю
__________________
Лучше сделать и жалеть, чем жалеть что не сделал |
|
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|