|
v7: проблема при изменении точки актуальности | ☑ | ||
---|---|---|---|---|
0
tt71071
06.07.15
✎
14:35
|
конфигурация Производство+услуги +.. 7.7 при изменении точки актуальности появляется ошибка Error #:-120 writing to File
...RG1247.DBF . САМ ФАЙЛ 2031М(огромный) . после появления ошибки в каталоге програмных файлов правились библиотеки seven.dll и dbeng32.dll (взято из статьи Kernel3x ) для того чтобы снять ограничение на размер базы. Результата не было. Понятно что нужно делать свёртку (архивирование периода) - однозначно но в процессе свёртки бухитогов проблема та же. а при свёртке регистров ругается на недостаток памяти. Какие ещё могут быть варианты (sql не подходит - дорогостоящий вариант) |
|||
1
Garykom
гуру
06.07.15
✎
14:41
|
(0) для начала сторонней прогой (тот же дбф нафигатор и т.д.) пожми (упаковка - удаление помеченных на удаление записей) этот RG1247.DBF
ЗЫ тока про бэкапы не забывать |
|||
2
Garykom
гуру
06.07.15
✎
14:42
|
(1)+ потом можно и извращаться со сверткой
|
|||
3
tt71071
06.07.15
✎
14:45
|
ок
|
|||
4
vladko
06.07.15
✎
15:16
|
(0) те обработки решают проблемы неставильной работы базы при превышении файла 1ГБ. А сама ДБФка не может быть более 2 ГБ, так что эти заплатки бесполезны при размере файла более 2 ГБ.
Свёртку можно попробовать сделать и под скулем, только потом его удалить после свёртки и продолжать пользоваться файловым режимом ;) |
|||
5
Mikeware
06.07.15
✎
15:17
|
Прежде всего, разберись, почему не закрывается этот регистр.
|
|||
6
tt71071
06.07.15
✎
15:19
|
походу нет никаких помеченных на удаление записей( упаковка таблиц уже делалась - dbf редакторы не находят
|
|||
7
tt71071
06.07.15
✎
15:20
|
к сожалению пока нет опыта при работе с регистрами
|
|||
8
Mikeware
06.07.15
✎
15:21
|
(7) "нет ножек - нет и мультиков"©
|
|||
9
Mikeware
06.07.15
✎
15:23
|
(8) как временный вариант для срочного родолжения работы - удалить в файле итогов самые старые периоды.
(естественно, сделав копию.) Но в первцю очередь - разбираться с закрытием регистра |
|||
10
Эльниньо
06.07.15
✎
15:26
|
Что за регистр?
|
|||
11
tt71071
06.07.15
✎
15:43
|
в файле dd указано что rg1247.dbf это регистр партии - может из него выборкой убрать старые записи 2008-2010 года а потом сжать или всё нужно делать только процедурой свёртки ?
|
|||
12
tt71071
06.07.15
✎
15:47
|
Mikeware - не могли бы с этого места поподробнее как можно разбираться с закрытием регистра ?
|
|||
13
ДенисЧ
06.07.15
✎
15:48
|
(12) Это программиста нужно позвать...
|
|||
14
Эльниньо
06.07.15
✎
15:51
|
"Нет регистра - нет проблем" ©
|
|||
15
Mikeware
06.07.15
✎
15:57
|
(13) или завести.....
|
|||
16
ДенисЧ
06.07.15
✎
15:59
|
(15) программист не таракан, чтобы его заводить...
|
|||
17
Mikeware
06.07.15
✎
16:01
|
||||
18
tt71071
06.07.15
✎
16:02
|
существенное уточнение .. гг
|
|||
19
Эльниньо
06.07.15
✎
16:09
|
Сколько лет базе?
|
|||
20
Mikeware
06.07.15
✎
16:10
|
(19) видимо, около семи...
|
|||
21
Эльниньо
06.07.15
✎
16:13
|
Есть один нехитрый способ, когда прогера и скуля нет.
Много лет назад на бухии прокатило. Должно и на оперучете проскочить |
|||
22
Garykom
гуру
06.07.15
✎
16:19
|
эээ имя файла rg*?
ёк... это надо было стока незакрытых партий развести по остаткам... |
|||
23
Garykom
гуру
06.07.15
✎
16:21
|
(22)+ вообщем простейший совет
копируете базу грохаете все документы оставляя только справочники (удаляя dbf-ки нужные) причем возможно справочник партии тоже того далее переносите нужные остатки и документы с текущей кривой базы |
|||
24
Mikeware
06.07.15
✎
16:25
|
(23) Зачем так грубо?
Можно просто немного почистить файл итогов (освободить место для текущих остатков), добиться того, чтоб регистр нормально закрывался, попровить движения, ну и пересчитать итоги только по этому регистру. |
|||
25
Garykom
гуру
06.07.15
✎
16:41
|
(24) "доктор сказал в морг - значит в морг"©
|
|||
26
Mikeware
06.07.15
✎
16:42
|
(25) "все б им, хирургам, резать... попрыгай - сами отвалятся!"©
|
|||
27
ДенисЧ
06.07.15
✎
16:53
|
(26) Дык уже отвалилось...
|
|||
28
tt71071
06.07.15
✎
16:58
|
я так понимаю , что немного почистить файл итогов - означает почистить в файле итогов нулевые записи или просто древние записи ?
|
|||
29
ДенисЧ
06.07.15
✎
17:02
|
(28) нулевые.
|
|||
30
Mikeware
06.07.15
✎
17:03
|
(27) Не, видишь - еще дергается...
(28) ну хотя бы нули почисти, если их дохрена. только не забудь после того переиндексироваться |
|||
31
tt71071
06.07.15
✎
17:12
|
в файле остатков нулевых записей не наблюдаю и не совсем понятно причём итоги если проблема с партиями ?
|
|||
32
Mikeware
06.07.15
✎
17:16
|
(31)
Однажды послали в космос двух собак и чукчу. Пошел первый виток, с Земли вызывают: - Белка! - Гав-гав! - Нажми красную кнопку! Пошел второй виток. - Стрелка! - Гав! - Нажми белую кнопку! Пошел третий виток. - Чукча! - Гав! - Ты чего гавкаешь?! Накорми собак и смотри, руками ничего не трогай! © |
|||
33
Злопчинский
06.07.15
✎
17:19
|
(31) смысл простой - в операциях прихода и в операциях расхода по партиям - набор измерений ДОЛЖЕН СОВПАДАТЬ.
например: Регистр Измерения - Фирма - Номенклатура - ПриходныйДокумент Приход - все понятно а расход тупой программер напрограммил, что списывается колво с указанием фирмы и номенклатуры... и все.. (_о_) |
|||
34
Garykom
гуру
06.07.15
✎
17:34
|
(33) остались 0 по номенклатуре и косяки (не нулевые) по партиям...
|
|||
35
tt71071
06.07.15
✎
17:49
|
ок , сейчас попробую убрать записи с нулевыми суммами
|
|||
36
Злопчинский
06.07.15
✎
18:21
|
||||
37
Злопчинский
06.07.15
✎
18:22
|
(35) ща ты наубираешь....
бэкап хоть сделай.. |
|||
38
tt71071
06.07.15
✎
18:34
|
я всё делаю на резервной базе
|
|||
39
tt71071
07.07.15
✎
06:29
|
убрать записи сторонней прогой - dbf редактором не получилось (слишком много записей >14млн.)- разные пробовал , а обработку скачать рейтинга не хватает , люди , кто-нибудь может отправить на мыло [email protected] ? http://catalog.mista.ru/public/180018/
|
|||
40
Garykom
гуру
07.07.15
✎
06:40
|
(39) слабо Access'ом открыть и запросом того?
это если XBase из 1С неизвестен... |
|||
41
tt71071
07.07.15
✎
06:49
|
уже утилитами напробовался - вчера ни одной адекватно не получилось - небольшие файлы да можно редактировать по запросам помечать на удадение а такой огромный файл как правило начинает отрабатывать и зависает
|
|||
42
Garykom
гуру
07.07.15
✎
06:50
|
(41) оно не зависает... оно думает!!!!
|
|||
43
tt71071
07.07.15
✎
06:52
|
возможно - бесконечно долго думает
|
|||
44
Garykom
гуру
07.07.15
✎
07:05
|
(43) гы... 14 лямов записей нет желания умножить на время обработки 1 записи (пусть 0,01 сек), затем поделить на 60 (получим в минутах) и еще раз на 60 (получим в часах) не?
|
|||
45
Garykom
гуру
07.07.15
✎
07:07
|
(44)+ у меня 38 часов вышло... примерно
|
|||
46
tt71071
07.07.15
✎
07:25
|
и причём не факт что это ещё что-то даст
|
|||
47
Mikeware
07.07.15
✎
07:27
|
(46) Ну, если освободишь место для текущих итогов - то даст. проработать еще месяц.
|
|||
48
Garykom
гуру
07.07.15
✎
07:28
|
(47) поэтому правильный ответ (23)
|
|||
49
Mikeware
07.07.15
✎
07:29
|
(48) правильный ответ - в (13)
|
|||
50
Garykom
гуру
07.07.15
✎
07:29
|
(49) гыы... он просто более универсальный а так =
|
|||
51
tt71071
07.07.15
✎
07:40
|
придётся передавать эту проблему в хорошие руки - фирме , которая занималась доработкой ( изменением) конфигурации от стандартной - возможно они чего-то и недосмотрели
|
|||
52
Garykom
гуру
07.07.15
✎
07:42
|
(51) %ом "хорошести" можно поинтересоваться?
|
|||
53
tt71071
07.07.15
✎
07:48
|
чем ?
|
|||
54
Garykom
гуру
07.07.15
✎
07:58
|
(53) контора "накосячила", Вы снова ей даете работу, чтобы она и дальше "косячила"
вот и интересна причина |
|||
55
tt71071
07.07.15
✎
08:25
|
она как бы обслуживает - обновление присылает и т.д
|
|||
56
tt71071
07.07.15
✎
08:41
|
может она и не накосячила ? может просто чаще свёртку нужно было делать - последний раз вроде бы делали 2008г.
|
|||
57
tt71071
07.07.15
✎
08:49
|
или косяки делают операторы
|
|||
58
FN
07.07.15
✎
09:18
|
(51) не давай им - они уже один раз накосячили.
У тебя тупо не закрывается регистр, даже если есть проблемы в учете разработчик должен был это предусмотреть, хотя бы в виде предупреждений/сообщений. |
|||
59
FN
07.07.15
✎
09:20
|
(56) сколько различных товаров в среднем на остатках, сколько приходных накладных в месяц?
|
|||
60
tt71071
07.07.15
✎
09:22
|
сейчас уточню
|
|||
61
FN
07.07.15
✎
09:26
|
и заодно размер RA1247.DBF скажи. Примерно будет ясно - можно ли на этой базе и дальше работать в ДБФ после закрытия регистра или все же нужно переходить на скл. Например Експресс - он бесплатный.
|
|||
62
tt71071
07.07.15
✎
09:29
|
накладных 100 прихдных 100 расходных , 400 перемещения итого 600 остатки материалы -20 товары - 30
rg1247.dbf - 2.03Гб |
|||
63
FN
07.07.15
✎
09:31
|
(62) я про RA спрашивал.
Документооборот смешной - скорее всего после решения проблемы с регистром еще можно будет жить в ДБФ. Могу помочь в нерабочее время. Почта в профиле. |
|||
64
tt71071
07.07.15
✎
09:32
|
експресс то может и бесплатный а за изменение 1с лицензии нужно будет платить и я подозреваю что немалую сумму
|
|||
65
FN
07.07.15
✎
09:35
|
64 ну есть такое. беглый гуглин показал цену в 36 тыр грн. Но думаю можно хорошую скидку выбить, или поискать б/у программу.
|
|||
66
tt71071
07.07.15
✎
09:40
|
RA1247.DBF - 603мб
|
|||
67
Garykom
гуру
07.07.15
✎
09:47
|
(66) тогда 100% косяки по незакрытым партиям в регистре
ЗЫ как может таблица всех движений (за все года) быть меньше чем таблица остатков (текущих) |
|||
68
Garykom
гуру
07.07.15
✎
09:48
|
(67) у Вас это должно было проявляться давно дикими тормозами при получении остатков товаров
|
|||
69
tt71071
07.07.15
✎
09:54
|
немного проясняется картина
|
|||
70
Mikeware
07.07.15
✎
09:56
|
(67) Ну вообще-то может... Если приход отделяет от расхода более 3 и более периодов - итоги будут вполне закономерно толще движений...
|
|||
71
Mikeware
07.07.15
✎
09:57
|
(68) остатки не по партиям получаются....
да и никаких тормозов при получении остатков при правильных индексах не будет. |
|||
72
tt71071
07.07.15
✎
10:08
|
важен вопрос причины - или кривая конфигурация или операторы
|
|||
73
Garykom
гуру
07.07.15
✎
10:19
|
(70) да согласен, если оборачиваемость никакая и штучный товар то вполне может быть такое
типа пришло и лежит, лежит, а в RG* каждый месяц на 1-е число плюсует записи по всем остаткам но тогда 200% что срочно свертку делать, хотя бы тупейшей чисткой из RG* старых периодов по которым остатки уже не нужны |
|||
74
Garykom
гуру
07.07.15
✎
10:19
|
(72) правильный ответ только один, кривой админ БД
|
|||
75
Mikeware
07.07.15
✎
10:29
|
(73) а если еще период итогов - не месяц, а меньше....
--------- решений, вообще говоря, "больше одного" --------- (72) ну так выясняйте причину. база-то у вас, а не у нас... не, у меня валяется где-то "анализ незакрываемости", но он для сиквела сделан (да и то, недоделан) - но можно и без него, глазиками... |
|||
76
tt71071
07.07.15
✎
15:14
|
вообщим переговорили с фирмой кот. осуществляет нам поддержку 1с - и они согласились свернуть базу но только до 2013 г.( в лучшем случае) и на это им нужно предварительно - 2 дня. Хорошо это или плохо сейчас особо выбор небольшой - ситуация сложная.
|
|||
77
Mikeware
07.07.15
✎
15:31
|
(76) а восстановить работоспособность и найти причину - пара часов.
|
|||
78
Ёпрст
07.07.15
✎
15:54
|
(0) огласите измерения регистра.
А так, путей несколько. самый простой - прибить прошлые итоги, получить текущие + свёртка. Или, прибить лишнюю аналитику в регистре. По-уму - смотреть причину незакрытия регистра, для начала, глядеть движения прихода и расхода - там почти сразу очевидно, из-за чего. |
|||
79
Ёпрст
07.07.15
✎
15:55
|
И.. скорее всего, какой-то му-2 добавил/изменил измерения регистра.
|
|||
80
Ёпрст
07.07.15
✎
15:55
|
из-за которых он перестал закрываться
|
|||
81
Garykom
гуру
07.07.15
✎
15:56
|
(77) за пару часов и заплотют "за пару часов"
а вот за "нужно предварительно - 2 дня" можно чуть побольше срубить |
|||
82
tt71071
07.07.15
✎
15:57
|
платиться за то что "фирма"
|
|||
83
Garykom
гуру
07.07.15
✎
16:01
|
(82) тогда не понял цель выноса этого вопроса на форум... который (0), сразу бы обратились к "фирма" и не тратили время
ЗЫ интересно что они 2-й день делают, как работают без смены ТА |
|||
84
Mikeware
07.07.15
✎
16:28
|
(83) при тех объемах им можно тупо курить это время. Никто и не заметит, что программа не работает. Это не 24*7*364, с допускаемыми 2 часами в месяц
|
|||
85
tt71071
07.07.15
✎
17:17
|
цель вынесения следующая - я искал пути решения проблемы но поскольку своими силами решить проблему не удалось ...
|
|||
86
tt71071
07.07.15
✎
17:18
|
как говорится : а счастье было так возможно ; и так - возможно ; и так - возможно
|
|||
87
tt71071
07.07.15
✎
17:21
|
если почистить регистр я как то и смог бы - то провести свёртку грамотно - я пока не готов
|
|||
88
Garykom
гуру
07.07.15
✎
17:36
|
(87) для свертки "типовых" есть "типовые обработки"
|
|||
89
Злопчинский
08.07.15
✎
01:12
|
Эмпирические исследования позволят сделать все малой кровью (читатйе Епрста). Если заведомо есть партии по которым СТОПУДОВО не должно быть итогов - то можно тупо прямыми запросами поудалять движения и итоги с такими партиями. Все резко похудеет. Но надо аккуратненько, аккуратненько.
|
|||
90
Злопчинский
08.07.15
✎
01:16
|
А свернуть вашу базу - два пальца об асфаль - свернуть именно технически.
1. внедрение универсального двигателя регистров - 10 мин. 2. заполнение УДР текущими остатками - ну пусть час... 3. удалить "лишнюю" аналитику (подменить креддокумент во взаиморасчетах на сам УДР и почистить ссылки на приходный доки в партиях - аналогично заменить на сам УДР). у себя именно так и сворачивал/разворачивал - п.2 делается автоматом с разбиением по докам с вменяемым количеством строк. |
|||
91
Злопчинский
08.07.15
✎
01:18
|
но это техническая свертка.
в результате получится может как было 100 приходов по Фирме1 и 100 расходов по фирме2 - так и останется. То есть незакрыто. Регистр-то порежется и дальше работать можно будет, но снова пухнуть начнет. а я - !!очень сомневаюсь!! что фирма которая "подрядилась" сделать свертку будет делать что-то иное, кроме как "технической" свертки. |
|||
92
Злопчинский
08.07.15
✎
01:19
|
Короче - если не взлетит и дургой пипл не поможет - стучись предметно как-нить попозжее (но ядумаю пипл поможет).
|
|||
93
FN
08.07.15
✎
10:03
|
Там проблема не только в RG1247. Есть еще один регистр на 905 метров и 1SENTRY уже перевалила за 1 гиг.
Так что либо полноценная свертка, либо переход на скуль. |
|||
94
tt71071
08.07.15
✎
18:48
|
спасибо всем , особенно FN , Злопчинскому нас потжимают сроки поэтому пришлось передать базу .. но в дальнейшем думаю что Ваша информация мне пригодится
|
|||
95
Эльниньо
09.07.15
✎
13:03
|
(94) В дальнейшем надо только одно - следить за размерами дбф
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |