|
v7: Проведение документа по регистрам и передвижение ТА Как объединить в одну транзакцию? | ☑ | ||
---|---|---|---|---|
0
Владимир1С
04.07.17
✎
11:15
|
Тема,собственно.
Столкнулся со следующим: При многопользовательской работе периодически отдельные пользователи попадают в ситуацию, когда в будущем(сегодня во времени) успел провестись документ, но платформа ещё не успела внести данные о новой позиции точки актуальности. При попадании проведения в этот физический промежуток времени система выдаёт сообщение "невозможно рассчитать итоги после ТА". .... По нормальной логике, проведение документа и внесение данных о новой позиции ТА должны быть неделимой операцией, но на практике происходит по-другому. Есть ли какой нибудь способ ликвидировать данную ситуацию как класс? |
|||
1
HawkEye
04.07.17
✎
11:16
|
(0) да, написать нормально код.
|
|||
2
Ёпрст
04.07.17
✎
11:17
|
в сервис параметры воткнуть галочки, наслаждаться, кушать печенки
|
|||
3
Владимир1С
04.07.17
✎
11:19
|
(1) Нарушить авторские права предлагаете? Воткнуть транзакцию на уровне плаформы?
(2) Прошу прощение за вопрос: А какая галочка на это влияет? |
|||
4
Ёпрст
04.07.17
✎
11:21
|
(3) на закладке Оперативный учет.
|
|||
5
Ёпрст
04.07.17
✎
11:21
|
там их не много
|
|||
6
Ёпрст
04.07.17
✎
11:22
|
одна из них, при проведении, сдвигает время документа и ставит ТА на него
|
|||
7
Владимир1С
04.07.17
✎
11:22
|
при проведении после ТА заменять врекмя на текущее?
|
|||
8
Ёпрст
04.07.17
✎
11:22
|
в результате, ТА всегда там, где надо
|
|||
9
Ёпрст
04.07.17
✎
11:23
|
(7) я не помню ужо, клюшки забросил :)
|
|||
10
1dvd
04.07.17
✎
11:25
|
можно клюшки отнять у человека, но нельзя человека отнять у клюшек © Почти
|
|||
11
Владимир1С
04.07.17
✎
11:33
|
(10)Не всегда гвозди стоит забивать паровым молотом, бывает достаточно и молотка.
|
|||
12
Владимир1С
04.07.17
✎
11:52
|
(6) У всех стоит галка "при проведении после ТА заменять время на текущее". При этом 4 пользователя(запускают автоматизирующую обработку) в параллели с ещё 6 другими(ручная работа) в основном получают адекватные ответы системы на запросы, а один из 4 периодически натыкается на 1SSystem на сервере, что проявляется двумя видами:полный отказ в проведении документов(Чуть ни каждый день, с учётом 3-х часовой ежедневной загрузки данных УРБД), и отказ в расчёте итогов после ТА(раз в месяц - два). Так что как то так.
|
|||
13
Ёпрст
04.07.17
✎
11:59
|
(12)из-за уриба может некорректно ТА вставать, на сколько я помню
|
|||
14
HawkEye
04.07.17
✎
12:03
|
(12) это у тебя происходит при работе 10 пользователей?
|
|||
15
Владимир1С
04.07.17
✎
12:03
|
(13) Этого я не знал. Большое спасибо.
|
|||
16
Владимир1С
04.07.17
✎
12:06
|
(14) всего 24 пользователя,+ 6 технических аккаунтов.
|
|||
17
AliAksA
04.07.17
✎
15:35
|
а не проще ли запихать ТА на месяц-два вперед?
|
|||
18
Владимир1С
04.07.17
✎
15:51
|
(17) Это выход, да. Спасибо.
|
|||
19
Джинн
04.07.17
✎
15:53
|
(17) (18) За такие советы убивать нужно.
|
|||
20
Владимир1С
04.07.17
✎
15:54
|
(19) в некоторых случаях это пригодно. При наличии излишних вычислительных мощностей. Можно и потерпеть отход от стандарта. У нас и так 1С++ крутится, база на SQL.
|
|||
21
Джинн
04.07.17
✎
15:58
|
(20) Вопрос не с стандарте, вопрос в падении скорости проведения документов в 5 раз.
|
|||
22
AliAksA
04.07.17
✎
16:04
|
(21) не гони волну - на нестандартных базах, когда "отборку товара" закидывают в конец месяца или планы выпуска на три месяца вперед, ещё никто не умирал,
а перевод ТА раз в месяц - обычная практика |
|||
23
Джинн
04.07.17
✎
16:18
|
(22) Обычная практика у рукожопых.
|
|||
24
AliAksA
04.07.17
✎
16:25
|
(23) для "умников": если ТА на конец месяца поставлена, он твоего торможения на скулевой базе ни одним органом не прочухает
|
|||
25
Джинн
04.07.17
✎
16:28
|
(24) Для тех, у кого рация на бронепоезде - любой документ начинает при проведении выполнять временный расчет итогов вместо того, чтобы получать готовые итоги на ТА. Производительность проведения при этом падает минимум в 5 раз. И в 5 раз растет время блокировки базы.
|
|||
26
Владимир1С
04.07.17
✎
16:34
|
(25) Это плохо. Но никак не лучше, когда вместо проведения документа юзер получает строку о невозможности получения итогов. Это 7.7, господа....
|
|||
27
Владимир1С
04.07.17
✎
16:34
|
Хотел написать "всёже лучше, чем "
|
|||
28
AliAksA
04.07.17
✎
16:35
|
(26) ыыыы, под стол ... временный расчет с какой точки?
и в чем разница если док проводится задним числом? и как заметить эту пресловутую разницу в 5 раз ? ну я не настолько могуч, чтобы отличить 0,02 сек от 0,1 ... |
|||
29
Владимир1С
04.07.17
✎
16:38
|
(28) Джинн прав, но: лучше получить проведение, чем никому ненужные строки о невозможности. И да, при 40 активных пользователях, уже придётся переходить на серверного робота-проводильщика.
|
|||
30
AliAksA
04.07.17
✎
16:47
|
(29) да не спорю, но в общую таблицу итогов ложится и будет менятся всего одна строка - на конец месяца,
а вот для перехода на серверного робота-проводильщика ты упаришся создавать ситуацию ... из опыта: на более 100Г-базе при активных 25 юзверях |
|||
31
AliAksA
04.07.17
✎
16:48
|
+(30) а вот с закидом на 3 месяца - чутка почуствовали торможение, но не умерли)
|
|||
32
AliAksA
04.07.17
✎
17:05
|
(29) ой сори, ТА ставь на 1 число след.месяца и проверь, чтобы периодичность в регистрах была "месяц":
нет заморочек со постоянными сдвигами ТА - тоже занимает время, не нужен быдлокод на сравнение КонДаты с ТА в отчетах и не нужен тот же перерасчет итогов в них |
|||
33
Джинн
04.07.17
✎
17:09
|
(28) Коллега, не городите херню. Этим Вы только свою бестолковость показываете.
|
|||
34
Джинн
04.07.17
✎
17:10
|
(29) Лучше найти причину и устранить ее, чем городить костыли.
|
|||
35
AliAksA
04.07.17
✎
17:15
|
(33) о да, вы каквсегда правы, коллега)
(29) ну да можно и гири пилить ... если время есть) |
|||
36
Владимир1С
04.07.17
✎
18:02
|
(34) Буду рад заменить Dll-ну на другую, которая процесс проведения с переносом ТА будет делать в одной транзакции. Ссылочку на скачивание дадите, коллеги?
|
|||
37
Джинн
04.07.17
✎
18:12
|
(36) Нельзя делать транзакцию внутри транзакции. Кроме того перенос ТА неотрывен от проведения документа. Нет никакого "промежутка времени". Вы ищете черную кошку в темной комнате. Дело не в этом. Дело в том, что какая-то зараза пишет документ на на ТА, а в "будущем времени". В сети, через РИБ или еще как.
|
|||
38
Владимир1С
04.07.17
✎
18:21
|
(37)... Данную версию наш комитет тоже скурпулёзно отработает и соберёт авторов. Спасибо.
|
|||
39
AliAksA
04.07.17
✎
18:21
|
(36) да передвинь уже точку ТА руками - проще будет,
держу пари, что Джин не сталкивался с ситуацией когда один документ открывается двумя пользователями одновременно , типа это невозможно, но факт - фактом, тогда клинит даже скулевую БД - вот ощутишь всю прелесть "передвижной" ТА |
|||
40
Владимир1С
04.07.17
✎
18:24
|
Всем спасибо, поеду на диван пить кофе. И вам всем того же желаю, мягкой и тёплой киски.
|
|||
41
Джинн
04.07.17
✎
18:32
|
(39) Нет, не сталкивался. Хотя на 7.7 лет 10 отработал и достаточно "плотными" базами.
|
|||
42
Diman_Kr
04.07.17
✎
18:39
|
Может это здесь работает, тогда пофиг галочки у ползователя?
ПроводитьПослеТА(<?>,); Синтаксис: ПроводитьПослеТА(<ФлагДляНеПров>,<ФлагДляПров>) Назначение: Установить режим проведения документа после ТА. Возвращает текущее значение режима перепроведения документа в зависимости от проведенности. Параметры: <ФлагДляНеПров> - режим проведения документа после ТА. Число: -1 (минус единица) - проводить документ всегда задним числом; 0 - при проведении запрашивать режим проведения документа; 1 - проводить документ в реальном потоке времени, т.е. при проведении время документа автоматически устанавливается на время после ТА. <ФлагДляПров> - режим перепроведения документа после ТА. Числовое выражение: -1 (минус единица) - проводить документ всегда задним числом; 1 - проводить документ в потоке. Замечание: Метод доступен только в Модуле формы документа и работает с документом доступным в локальном контексте. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |