Ошибка 1С SQL
Показывать по
10
20
40
сообщений
- 1
- 2
07.04.2008
14:33
#1
1С 7.7 SQL 7.70.025, конфигурация бухгалтерия, релиз последний.
При формировании отчётов (напр. ОСВ или карточки счёта) некоторые группы "выпадают" из отчётов. Например:
Должно быть:
ГРУППА_1 100
- позиция_11 50
- позиция_12 50
ГРУППА_2 200
- позиция_21 50
- позиция_22 50
- позиция_23 50
- позиция_24 50
ГРУППА_3 200
- позиция_21 50
- позиция_22 50
- позиция_23 50
- позиция_24 50
ИТОГО 600
Получается напр. так:
- позиция_11 50
- позиция_12 50
ГРУППА_2 200
- позиция_23 50
- позиция_24 50
ГРУППА_3 200
- позиция_21 50
- позиция_22 50
- позиция_23 50
- позиция_24 50
ИТОГО 600
Т.е. группы и части элементов в группах "выпадают" из отчёта. Причём это не ошибка кода (код типовой), а результат возвращаемый объектом БухгалтерскиеИтоги. При каждом новом формировании результат не повторяется, но почти никогда не возвращается всё что должно.
При переводе базы в формат DBF ошибка исчезает. Перевести в DBF нельзя, слишком много пользователей, слишком большой размер базы.
Тестирование и исправление сделаны, выгрузка-загрузка тоже. Результат отрицательный, ошибка сохранилась. На том же SQL Server'е находятся ещё несколько бух. баз (правда меньшего чем эта размера), и в них подобной ошибки не наблюдается.
В чём может быть ошибка? И как собственно её исправить?
Какие будут варианты?
При формировании отчётов (напр. ОСВ или карточки счёта) некоторые группы "выпадают" из отчётов. Например:
Должно быть:
ГРУППА_1 100
- позиция_11 50
- позиция_12 50
ГРУППА_2 200
- позиция_21 50
- позиция_22 50
- позиция_23 50
- позиция_24 50
ГРУППА_3 200
- позиция_21 50
- позиция_22 50
- позиция_23 50
- позиция_24 50
ИТОГО 600
Получается напр. так:
- позиция_11 50
- позиция_12 50
ГРУППА_2 200
- позиция_23 50
- позиция_24 50
ГРУППА_3 200
- позиция_21 50
- позиция_22 50
- позиция_23 50
- позиция_24 50
ИТОГО 600
Т.е. группы и части элементов в группах "выпадают" из отчёта. Причём это не ошибка кода (код типовой), а результат возвращаемый объектом БухгалтерскиеИтоги. При каждом новом формировании результат не повторяется, но почти никогда не возвращается всё что должно.
При переводе базы в формат DBF ошибка исчезает. Перевести в DBF нельзя, слишком много пользователей, слишком большой размер базы.
Тестирование и исправление сделаны, выгрузка-загрузка тоже. Результат отрицательный, ошибка сохранилась. На том же SQL Server'е находятся ещё несколько бух. баз (правда меньшего чем эта размера), и в них подобной ошибки не наблюдается.
В чём может быть ошибка? И как собственно её исправить?
Какие будут варианты?
07.04.2008
17:52
#2
"А может быть стоит привести текст запроса? или мы должны угадать? ;)
З.Ы. Только потом прочитал вопрос
, т.е. отчеты стандартные или переделанные?"
З.Ы. Только потом прочитал вопрос
08.04.2008
09:15
#4
никогда такого не наблюдалось у клиентов на 25-м релизе, можно попробовать обновить платформу до 027 релиза
08.04.2008
09:25
#5
Попробуйте "Выгрузить-Загрузить" базу... Причем тестирование и исправление базы с пересчетом бухитогов может и не решить проблему. Так что именно "Выгрузить-Загрузить"
08.04.2008
09:28
#6
> никогда такого не наблюдалось у клиентов на 25-м релизе, можно попробовать обновить платформу до 027 релиза
Наблюдалось. И на 025 и на 027, без разницы.
Именно описанным способом: запрос при заполнении документв всегда возвращал разное, произвольное количество строк, разброс был от 90 строк (не правильно) до 150 (что и было правильно), причем каждый раз случайный результат.
Дело оказалось в антивирусе ВDr.Web, не был обновлен и не были настроены исключения на расширения файлов .dbf и .cdx. Как именно ити исключения влияли на SQL - не понятно! ЬТем более, что та же база под той же оболочкой но в DBF работала правильно. В то же самое время на машинах с Касперским запросы с этой же базой выполнялись правильно, заже без настроенных исключений. Загадка природы!
После обновления Dr.Web и настройки исключений - все в порядке.
Наблюдалось. И на 025 и на 027, без разницы.
Именно описанным способом: запрос при заполнении документв всегда возвращал разное, произвольное количество строк, разброс был от 90 строк (не правильно) до 150 (что и было правильно), причем каждый раз случайный результат.
Дело оказалось в антивирусе ВDr.Web, не был обновлен и не были настроены исключения на расширения файлов .dbf и .cdx. Как именно ити исключения влияли на SQL - не понятно! ЬТем более, что та же база под той же оболочкой но в DBF работала правильно. В то же самое время на машинах с Касперским запросы с этой же базой выполнялись правильно, заже без настроенных исключений. Загадка природы!
После обновления Dr.Web и настройки исключений - все в порядке.
08.04.2008
09:31
#7
Не поможет, скорее всего. Мне не помогло, пока не "причесали" антивирус. Вот перевод обратно в DBF - все работало правильно.
- 1
- 2
Читают тему
(гостей: 1)