1С++ users forum - Долгое открытие периода оперативных итогов и сдвиг ТА

(UTC)

1С++ users forum › 1С++ и прочие расширения v7 › Прямые запросы к БД › Долгое открытие периода оперативных итогов и сдвиг ТА

(Группа Модераторов: 1c++ moderator)

‹ Предыдущая Тема | Следующая Тема ›

Переключение на Главную Страницу

Страницы: 1 2 [3] 4

Отправить

Очень популярная тема (более 25 ответов)

Долгое открытие периода оперативных итогов и сдвиг ТА (число прочтений - 15118 )

Eprst God Member Отсутствует Сообщений: 3397 Зарегистрирован: 08. Октября 2007	Re: Долгое открытие периода оперативных итогов и сдвиг ТА Ответ #30 - 10. Февраля 2010 :: 16:40	Печать
	Я баловался с правкой дд... но получал неверные результаты в итоге.. Ужо не помню, давно было.. Да и тов. ромикс написал же: "Убираю статью, т.к. были обнаружены неполадки с этим методом." Лучше всё же структуру регистра переделать, чем с индексами в дд играться.


	IP записан

artbear 1c++ developer 1c++ moderator Отсутствует Эх, дайте что-нибудь новенькое да полезное потести Сообщений: 6303 Местоположение: Москва Зарегистрирован: 19. Мая 2006 Пол:	Re: Долгое открытие периода оперативных итогов и сдвиг ТА Ответ #31 - 11. Февраля 2010 :: 04:28	Печать
	Очень хотелось бы узнать, что становится неверным?

	OpenConf developer :: http://openconf.1cpp.ru&&FormEx developer :: http://formex.dorex.ru&&1C++ active developer && tester :: www.1cpp.ru
	GTalkSkype/VoIP ICQ IP записан

Eprst God Member Отсутствует Сообщений: 3397 Зарегистрирован: 08. Октября 2007	Re: Долгое открытие периода оперативных итогов и сдвиг ТА Ответ #32 - 11. Февраля 2010 :: 05:58	Печать
	Итоги неверные получаются.. Т.е Остаток + Приход-Расход <> Остаток след. периода.


	IP записан

kiruha 1c++ power user Отсутствует Сообщений: 1249 Зарегистрирован: 11. Апреля 2007	Re: Долгое открытие периода оперативных итогов и сдвиг ТА Ответ #33 - 11. Февраля 2010 :: 11:48	Печать
	Была такая проблема. Период открывался около 30 мин на базе в 100Мб Оказалось что в регистре партий лежало измерение ГТД (ТИС 8 кажется) - тип строка 13 (или 20 ?), Страна - строка 10 после заведения справочника номеров ГТД и стран - проблема полностью исчезла (открытие меньше минуты) Думаю 1С некорректно работает со строковыми измерениями. Также подобную проблему подымали на Итланде - также решили ее таким же образом


	IP записан

Z1 God Member Отсутствует I Love YaBB 2! Сообщений: 2906 Местоположение: Москва Зарегистрирован: 26. Мая 2006 Пол:	Re: Долгое открытие периода оперативных итогов и сдвиг ТА Ответ #34 - 11. Февраля 2010 :: 13:30	Печать
	kiruha писал(а) 11. Февраля 2010 :: 11:48: Была такая проблема. Период открывался около 30 мин на базе в 100Мб Оказалось что в регистре партий лежало измерение ГТД (ТИС 8 кажется) - тип строка 13 (или 20 ?), Страна - строка 10 после заведения справочника номеров ГТД и стран - проблема полностью исчезла (открытие меньше минуты) Думаю 1С некорректно работает со строковыми измерениями. Также подобную проблему подымали на Итланде - также решили ее таким же образом неправильно 1с великолепно работает со строковыми измерениями. Любое измерение когда конкретный справочник это char(9). 1с очень плохо работает с незакрывающимися регистрами независимо от типа измерения. В данном случае когда измерение есть float шансов закрыться регистру практически никаких нет.


	IP записан

kiruha 1c++ power user Отсутствует Сообщений: 1249 Зарегистрирован: 11. Апреля 2007	Re: Долгое открытие периода оперативных итогов и сдвиг ТА Ответ #35 - 11. Февраля 2010 :: 14:34	Печать
	Z1 писал(а) 11. Февраля 2010 :: 13:30: kiruha писал(а) 11. Февраля 2010 :: 11:48: Была такая проблема. Период открывался около 30 мин на базе в 100Мб Оказалось что в регистре партий лежало измерение ГТД (ТИС 8 кажется) - тип строка 13 (или 20 ?), Страна - строка 10 после заведения справочника номеров ГТД и стран - проблема полностью исчезла (открытие меньше минуты) Думаю 1С некорректно работает со строковыми измерениями. Также подобную проблему подымали на Итланде - также решили ее таким же образом неправильно 1с великолепно работает со строковыми измерениями. Любое измерение когда конкретный справочник это char(9). 1с очень плохо работает с незакрывающимися регистрами независимо от типа измерения. В данном случае когда измерение есть float шансов закрыться регистру практически никаких нет. Я описываю реальную ситуацию на ДБФ. И также вполне реально еще несколько человек решило эту проблему. Видимо пересчет итогов идет по спец. алгоритму. По поводу незакрытых регистров - не гуд конечно, но вполне в приемлемые сроки пересчитывает. У народа встречались регистры и под 1гб ДБФ.


	IP записан

kiruha 1c++ power user Отсутствует Сообщений: 1249 Зарегистрирован: 11. Апреля 2007	Re: Долгое открытие периода оперативных итогов и сдвиг ТА Ответ #36 - 11. Февраля 2010 :: 14:46	Печать
	Один из примеров "тупых" алгоритмов в 1С ДБФ с которым сталкивался - расчет временных итогов регистра с фильтрацией по номенклатуре и наличием индексов итога и движений по этому полю - если номенклатура одна - индекс используется , если же 2 - идет полный пересчет по всем товарам и только потом из результата выделяется нужные. Вместо доли сек (без транзакции) - расчет идет минуту.


	IP записан

Timka YaBB Newbies Отсутствует 1C++ rocks! Сообщений: 6 Зарегистрирован: 30. Июля 2011	Re: Долгое открытие периода оперативных итогов и сдвиг ТА Ответ #37 - 30. Июля 2011 :: 15:57	Печать
	Господа, пришел к вам с той же проблемой - открытие периода происходит невообразимо долго. Сейчас на Core2Duo E8400 при размещении базы целиком в RAM-диске это занимает более 50 (!) часов. База около 1G, почитав эту тему понял, что проблема все-таки в незакрытых регистрах - если ra.dbf занимают 47М, то rg.dbf - 780М. Конфигурация ТиС, но, как водится, дописанная кем-то криворуким. Все усугубляется тем, что в 1с я чайник, а вопрос решить нужно максимально быстро, нет времени искать кого-то грамотного, пару раз обращались к разным людям/фирмам, никто не смог помочь, а сейчас уже прижало конкретно. Вдруг кому-то тут не лень будет объяснить, как мне самостоятельно локализовать проблему и исправить, не потеряв имеющихся данных и прочей работоспособности - буду благодарен. В любом случае, спасибо уже за то, что дочитали


	IP записан

Satans Claws God Member Отсутствует 1C++ rocks! Сообщений: 721 Зарегистрирован: 29. Ноября 2010	Re: Долгое открытие периода оперативных итогов и сдвиг ТА Ответ #38 - 01. Августа 2011 :: 03:18	Печать
	leshik писал(а) 02. Февраля 2010 :: 15:04: Кратко анализ делается так - берется соотношение таблиц RG и RA - обычно RG должен составлять 1/3 - не более от RA (по своему опыту). Все что не подпадает под это определение должно быть проанализировано. Т.е. или регистры не закрываются, или ТА перетащили в какие-то гремучие дребеня, потипу 2111 года. 95%, что дело в незакрытии регистров. "Быстрого" решения нет - нужно искать, какие документы делают неправильные движения, менять алгоритмы + как-то разруливать текущий хаос (перепроведение - не лучший выход). Хотя, в качестве быстрого решения - создать документ (или дописать кусок в закрытие месяца), который проходит по регистру и "закрывает" его, и раз в месяц его проводить.


	IP записан

Timka YaBB Newbies Отсутствует 1C++ rocks! Сообщений: 6 Зарегистрирован: 30. Июля 2011	Re: Долгое открытие периода оперативных итогов и сдвиг ТА Ответ #39 - 01. Августа 2011 :: 06:06	Печать
	Мда, с моими знаниями 1с это звучит не очень обнадеживающе А "закрытие" регистра как происходит?


	IP записан

Z1 God Member Отсутствует I Love YaBB 2! Сообщений: 2906 Местоположение: Москва Зарегистрирован: 26. Мая 2006 Пол:	Re: Долгое открытие периода оперативных итогов и сдвиг ТА Ответ #40 - 01. Августа 2011 :: 06:13	Печать
	Timka писал(а) 30. Июля 2011 :: 15:57: Господа, пришел к вам с той же проблемой - открытие периода происходит невообразимо долго. Сейчас на Core2Duo E8400 при размещении базы целиком в RAM-диске это занимает более 50 (!) часов. База около 1G, почитав эту тему понял, что проблема все-таки в незакрытых регистрах - если ra.dbf занимают 47М, то rg.dbf - 780М. Конфигурация ТиС, но, как водится, дописанная кем-то криворуким. Все усугубляется тем, что в 1с я чайник, а вопрос решить нужно максимально быстро, нет времени искать кого-то грамотного, пару раз обращались к разным людям/фирмам, никто не смог помочь, а сейчас уже прижало конкретно. Вдруг кому-то тут не лень будет объяснить, как мне самостоятельно локализовать проблему и исправить, не потеряв имеющихся данных и прочей работоспособности - буду благодарен. В любом случае, спасибо уже за то, что дочитали Опишите база sql dbf Есть терминал или нет Число активно работающих пользователей. Самый быстрый путь обрезать базу на 01.01.2011


	IP записан

Eprst God Member Отсутствует Сообщений: 3397 Зарегистрирован: 08. Октября 2007	Re: Долгое открытие периода оперативных итогов и сдвиг ТА Ответ #41 - 01. Августа 2011 :: 06:25	Печать
	Timka писал(а) 30. Июля 2011 :: 15:57: ra.dbf занимают 47М, то rg.dbf - 780М. находишь одноименные таблички,где RG>RA, открываешь словарик(*.dd) выписываешь сюда имена этих регистров. У тебя это скорее всего ПартииНаличие или Покупатели или Заявки/Резервы... Далее, нужно анализировать, по какому измерению не закрывается и думать, что делать - либо кастрировать, либо исправлять алгоритмы - перепровести, либо просто "закрыть" корректировочным документом, либо свернуть базу и избавиться от лишней аналитики.


	IP записан

Timka YaBB Newbies Отсутствует 1C++ rocks! Сообщений: 6 Зарегистрирован: 30. Июля 2011	Re: Долгое открытие периода оперативных итогов и сдвиг ТА Ответ #42 - 02. Августа 2011 :: 20:40	Печать
	Eprst писал(а) 01. Августа 2011 :: 06:25: Timka писал(а) 30. Июля 2011 :: 15:57: ra.dbf занимают 47М, то rg.dbf - 780М. находишь одноименные таблички,где RG>RA, открываешь словарик(.dd) выписываешь сюда имена этих регистров. У тебя это скорее всего ПартииНаличие или Покупатели или Заявки/Резервы... У меня все RG больше аналогичных им RA. где-то сами dfb небольшие - десятки, сотни килобайт, думаю они проблем не доставляют, а где-то есть за сотню мегабайт RG и в деять-пятнадцать раз меньше соответствующий ему RA. RG405 - Остатки ТМЦ (198М против 12М) RG328 - ПартииНаличие (126М против 13М) RG4480 - РезервыТМЦ (87М против 7М) RG4674 - Заявки (37М против 3М) RG4343 - КнигаПродаж (35М против 2М) RG4335 - Покупатели (33М против 1.5М) Остальные dbf небольшого размера и вряд ли сильно влияюн на общую ситуацию. Eprst писал(а) 01. Августа 2011 :: 06:25:* Далее, нужно анализировать, по какому измерению не закрывается и думать, что делать - либо кастрировать, либо исправлять алгоритмы - перепровести, либо просто "закрыть" корректировочным документом, либо свернуть базу и избавиться от лишней аналитики. В принципе, меня бы устроил вариант с корректировочным документом или любым другим способом, не требующим много времени Вопрос только в том, как это сделать...


	IP записан

Eprst God Member Отсутствует Сообщений: 3397 Зарегистрирован: 08. Октября 2007	Re: Долгое открытие периода оперативных итогов и сдвиг ТА Ответ #43 - 03. Августа 2011 :: 05:29	Печать
	Ну, если у тебя даже остатки не не закрываются, то тут вообще всё плохо. Проще разобраться почему, или.. свернуть базу + избавиться от лишней аналитики. Вот только если она вам нужна будет, то придётся разбираться с "незакрытием". ЗЫ: не в розницу, случаем торгуете ?


	IP записан

Timka YaBB Newbies Отсутствует 1C++ rocks! Сообщений: 6 Зарегистрирован: 30. Июля 2011	Re: Долгое открытие периода оперативных итогов и сдвиг ТА Ответ #44 - 03. Августа 2011 :: 05:49	Печать
	торгуем природным камнем, из которого еще делаются изделия - типа подоконников, столешниц и пр. он приходит в виде цельных плит определенной площади, а изделия, как правило, продаются меньшей площади - отсюда могут накапливаться постоянные остатки, не дающие закрыть регистр. я правильно мыслю?


	IP записан

Переключение на Главную Страницу

Страницы: 1 2 [3] 4

Отправить

‹ Предыдущая Тема | Следующая Тема ›

« Главная ‹ Раздел Вверх

Вверх

Valid XHTML

Valid CSS

Powered by Perl

Source Forge