0
- 26.06.2014 - 16:38
|
Итак, дописанная 7.7 Буха. Пользователи ругаются на некорректную работу. 3 раза последовательно сделанное ТИИ выдает кучу ошибок. На 4 раз ошибок нет. DrMD говорит - ошибок нет. Делаем оборотку по сч60 по конкретному контрагенту, среди Услуг сторонних организаций маячит "Платежное поручение", которое-то и проводок не формирует. При попытке расшифровать запись открывается платежка, в которой совершенно другая организация. Документы за период перепроводил- без толку. Капец...
| | |
1
- 26.06.2014 - 16:45
|
1. Проверить комп на вирусы. 2. Проверить работу базы на другом компе. | | |
2
- 26.06.2014 - 16:50
| 3. Заплатить уволенному программисту. | | |
3
- 26.06.2014 - 16:56
| Забрали на другой комп, закинул на RAM-диск, загрузку-выгрузку делали. Шаманим дальше... | | |
4
- 26.06.2014 - 16:58
| toТкачик - до и после "случая Х" осблуживает франч, поэтому этот момент исключается ))) | | |
5
- 26.06.2014 - 16:59
| а поинтересуйтесь у обновляльщика, не делал ли он обновлений подменой md-файла когда-либо | | |
6
- 26.06.2014 - 17:01
| toЗелёный тролль - бывают конечно умники, но что-бы настолько.... Да я думаю и не сознается (( | | |
7
- 26.06.2014 - 17:06
| мало вводных... после (3) ничего не изменилось? что еще "не так" в базе? | | |
8
- 26.06.2014 - 17:08
| to user1C : абсолютно ничего не поменялось. Пользователь указал на явный косяк. | | |
9
- 26.06.2014 - 17:22
|
(8) "3 раза последовательно сделанное ТИИ выдает кучу ошибок." каких ошибок? конкретней... | | |
10
- 26.06.2014 - 17:27
|
(9) Первый прогон https://yadi.sk/i/tb8Sz_xWUzmwC | | |
11
- 26.06.2014 - 17:31
|
(9) Второй https://yadi.sk/i/g-uor7BzUznXH . Особо смущает фраза"Вн. идентификатор VWW Исправить вручную" | | |
12
- 26.06.2014 - 17:43
| Накатил правдами-неправдами последний релиз , ситуация не изменилась. Похоже лечится только удалением документа, на который идет ссылка.... | | |
13
- 26.06.2014 - 19:30
| русским же языком написано: дублирование идентификаторов - плющить надо рукми, иначе бо-бо будет | | |
14
- 27.06.2014 - 05:55
| Цитата:
| | |
15
- 27.06.2014 - 08:50
| (14) я так понимаю, идентификатор должен быть уникален среди всех идентификаторов базы, а не только в пределах одного D*.dbf ? Корявых записей не много, может проще их изничножить? | | |
16
- 27.06.2014 - 09:08
|
15-Alp78 > 1.Нет. 2. Нет. Лучше бы ты не лез туда. С такими-то знаниями... | | |
17
- 27.06.2014 - 09:12
|
(15) изничтожать тоже надо грамотно и вдумчиво... Описание таблиц 1С V77 | | |
18
- 27.06.2014 - 09:14
| (16) дык просвяти.. | | |
19
- 27.06.2014 - 09:35
|
18-Alp78 > Я не апостол, чтоб просвящать. И не учитель, чтоб просвещать. Скажу так: беда не в файлах. Это следствие. В файл-сервере - корень проблем. И, небось, когда юзера просят переиндексировать базу, он с презрением отказывается? | | |
20
- 27.06.2014 - 09:47
|
Сорри, описАлся ( Помоги! Полцарства за решение ! (2 dbf тут https://yadi.sk/d/q6m6LMAtV3oP8 ) | | |
21
- 27.06.2014 - 09:49
| (18) В понедельник поеду в ту контору - буду разбираться, что к чему.. Пока имею только "корявую" базу, присланную по почте | | |
22
- 27.06.2014 - 10:07
| Я думаю, что исправлять вслепую только два файла бессмысленно, надо смотреть всю базу. Причем, возможно, вручную ковырять придется исходный вариант, который до всех ТиИ. | | |
23
- 27.06.2014 - 10:50
| Наблюдал регулярный поток бессистемных ошибок в базе в случае достижения любым из файлов размера около 1Г. Лечится только уменьшением размера файла (удалением данных) либо SQL. | | |
24
- 27.06.2014 - 10:54
|
(23) база 200 Мб, думаю не наш случай | | |
25
- 27.06.2014 - 11:18
|
После ручного удаления записей в соответствующих DBF ,при ТИИ имеем следующее: Проверка таблиц документов. Документ ОказаниеУслуг(DH321. Запись 1369). Нет в журнале документов Проверка таблиц документов. Документ ОказаниеУслуг(DH321. Запись 1374). Нет в журнале документов Проверка таблиц документов. Документ СчетФактура(DH11012. Запись 3788). Нет в журнале документов Проверка таблиц документов. Документ СчетФактура(DH11012. Запись 3794). Нет в журнале документов Проверка таблиц документов. Документ Счет(DH12517. Запись 3228). Нет в журнале документов Проверка таблиц документов. Документ Счет(DH12517. Запись 3233). Нет в журнале документов Проверка таблиц документов. Документ УслугиСтороннихОрганизаций(DH13163. Запись 4499). Нет в журнале документов Проверка таблиц документов. Табл. часть документа ОказаниеУслуг(DT321. Запись 1402). Нет в журнале документов Проверка таблиц документов. Табл. часть документа ОказаниеУслуг(DT321. Запись 1407). Нет в журнале документов Проверка таблиц документов. Табл. часть документа СчетФактура(DT11012. Запись 4574). Нет в журнале документов Проверка таблиц документов. Табл. часть документа СчетФактура(DT11012. Запись 4580). Нет в журнале документов Проверка таблиц документов. Табл. часть документа Счет(DT12517. Запись 3945). Нет в журнале документов Проверка таблиц документов. Табл. часть документа Счет(DT12517. Запись 3950). Нет в журнале документов Проверка таблиц документов. Табл. часть документа УслугиСтороннихОрганизаций(DT13163. Запись 4544). Нет в журнале документов | | |
26
- 27.06.2014 - 12:24
|
25-Alp78 >Вот и именно: ибо каждый документ имеет уникальный идентификатор не только в пределах своего журнала (а это и есть DH*.DBF), но и в общем журнале документов. Я так понимаю, ресурс http://www.script-coding.com/v77tables.html был с презрением отвергнут? | | |
27
- 27.06.2014 - 12:24
| 25-Alp78 > не возникло вопроса "где платёжное поручение из сабжа"? | | |
28
- 27.06.2014 - 12:33
|
(26) Не, ресурс- в закладки,в выходные буду изучать | | |
29
- 27.06.2014 - 12:35
|
(27) Записи из сабжа изничтожены вручную из DBF, документы потом забьём ручками | | |
30
- 27.06.2014 - 12:56
|
29-Alp78 > Правильно, вообще-то, не уничтожать. Правильно сравнивать нужные таблицы из рабочей базы с соответствующими таблицами из бэкапа. А бэкап надо делать когда он не нужен. Когда нужда появилась - это уже поздно. И ТиИ надо регулярно делать. Желательно, когда тоже не нужно. А для переидексации и про "нужно" не надо думать: как никто не думает, надо ли одевать штаны перед выходом на улицу. | | |
31
- 27.06.2014 - 13:02
| (29) Нет бэкапа. Точнее есть, но годовалой давности. Считай что нет. А с высказыванием - согласен. | | |
32
- 27.06.2014 - 13:05
| 0-> удалить файл проводок, отбора счетов и перепровести всю базу (можно поставить на ночь). Как вариант - не трогать файл проводок и удалить тока файл отбора счетов, сделать тестирование и исправление | | |
33
- 27.06.2014 - 13:09
| (32) попробую. Спасибо! | | |
34
- 27.06.2014 - 13:21
| 29-Alp78 > записи изничтожены - ладно, а в ОСВ что, не осталось платёжек в субконто? сомневаюсь сильно | | |
35
- 27.06.2014 - 13:26
|
(34) Документы из (10) руками удалены (до этого они были недоступны для редактирования) | | |
36
- 27.06.2014 - 13:57
| 35-Alp78 > что гарантирует непоявление подобных документов в будущем? | | |
37
- 27.06.2014 - 14:17
| (36) Предположение- Во время работы был какой-то сбой, аварийный выход. После сбоя переиндексация не был произведена, а работа продолжена. В результате у нескольких документов проводки остались в базе, а самих документов не осталось. При продолжении работы вновь создававшиеся документы получали те же идентификаторы внутренние, которые были у тех слетевших в момент сбоя... | | |
38
- 27.06.2014 - 14:31
|
(пере)индексация не влияет на присвоение идентификатора записи таблицы. индексация переформирует файлы индексов, для правильного и быстрого построения отчетов (выборок). то есть если бы только отчеты не правильно формировались, то переиндексации было бы возможно достаточно. а вот появление дублей индентификаторов переиндексацией никак не лечится. тут надо смотреть md. имхо. | | |
39
- 27.06.2014 - 23:06
|
38-Зелёный тролль > Не только, не только... Как формируется новый ID, в курсе? Прааально, инкрементом. От максимального значения. А как находится это максимальное значение? Прааально, назначается индекс по ID, и на EOF ;) А нсли индекс чудит, а? | |
| Интернет-форум Краснодарского края и Краснодара |