Ошибка в полях FlowField

[Rimas]

Обнаружилась вот такая проблема со значениями вычисляемых полей (FlowField): в таблице 27 Items значение "Transferred (Qty.)" не совпадает с сумой полей, по которым происходит суммирование, т.е. Sum("Item Ledger Entry"."Invoiced Quantity" WHERE...
Данные, иллюстрирующие проблему: [attachment=1151:Данные.xls]
Используем Navision v4 и SLQ Server 2000.
Но когда на локальной машине восстанавливаю базу данных с копии, суммирование происходит правильно. Суммирование производиться на основе ключей, которые создаются заново при восстановлении БД с копии средствами Navision. Это наводит на мысль, что надо переделать индексы на сервере. Но DBCC DBREINDEX("dbo.ххх$Item Ledger Entry") не дало результата.

Может кто встречался с такой проблемой и поделиться знаниями, как ее решить?

[Eugeny_F]

Цитата:

Сообщение от Rimas

Обнаружилась вот такая проблема со значениями вычисляемых полей (FlowField): в таблице 27 Items значение "Transferred (Qty.)" не совпадает с сумой полей, по которым происходит суммирование, т.е. Sum("Item Ledger Entry"."Invoiced Quantity" WHERE...
Данные, иллюстрирующие проблему: [attachment=1151:Данные.xls]
Используем Navision v4 и SLQ Server 2000.
Но когда на локальной машине восстанавливаю базу данных с копии, суммирование происходит правильно. Суммирование производиться на основе ключей, которые создаются заново при восстановлении БД с копии средствами Navision. Это наводит на мысль, что надо переделать индексы на сервере. Но DBCC DBREINDEX("dbo.ххх$Item Ledger Entry") не дало результата.

Может кто встречался с такой проблемой и поделиться знаниями, как ее решить?

Попробуйтe:
1. Сделать данное поле обычным (Normal).
2. Сохраните структуру таблицы.
3. Сделайте данное поле обратно FlowField

[Rimas]

Это не помогает - результат тот же.

[prefreitor]

Сталкивался с подобной проблемой, теже самые таблицы, поля помойму другие были. Лечилось так:
1) Выгрузка ТКО в fob
2) выключением всех ключей, кроме первичного в ТКО
3) Импорт ТКО из Fob- a
Глюк исчез или после смены версии клиента или перехода на SQL 2005, точно причину установить не удалось.
P.S здесь ошибка однозначно 32 таблице а не в 27. Если по 32 таблице сделать по этому полю с таким же ключем CALCSUMS, то результат будет также неверный.

[apanko]

http://forum.mazzy.ru/index.php?showtopic=12434

Оно?

[Storkich]

Предположу, что в какой-то момент не отработали SQL триггеры на табличке. Либо отключили, либо ручками что-то правили, либо утилитка нехорошая. В свойствах ключей есть поле "MaintainSIFTIndex" записать в него "No" сохранить, вернуть как было и опять сохранить.

[Rimas]

Цитата:

Сообщение от prefreitor

Сталкивался с подобной проблемой, теже самые таблицы, поля помойму другие были. Лечилось так:
1) Выгрузка ТКО в fob
2) выключением всех ключей, кроме первичного в ТКО
3) Импорт ТКО из Fob- a
Глюк исчез или после смены версии клиента или перехода на SQL 2005, точно причину установить не удалось.
P.S здесь ошибка однозначно 32 таблице а не в 27. Если по 32 таблице сделать по этому полю с таким же ключем CALCSUMS, то результат будет также неверный.

Попробовал этот метод - ключи снял успешно.
Две попытки восстановить таблицы из fob'а закончились одинаково: сервер свалился, не сумев создать индексы.
[attachment=1153:error.JPG]
Думаю, что делать дальше - с утра БД должна быть в рабочем состоянии

[Sancho]

попробовать создать пустую базу (тестовую? демонстрационную?), налить фоб туда. если записей мало, то справится.
там в другой базе снять галочки с ключей, выгрузить в фоб.
залить фоб в боевую и включать ключи по-одному с последующей перекомпиляцией

[Rimas]

спасибо за совет, но додумалься и сам: востанавливание по паре индексов разрешает держать сервер в рабочеспособном состоянии и процесс востановления индексов медленно, но движется вперед.

[Rimas]

Спасибо всем за советы. Не всеми воспользовался, так как пробовал по порядку поступления

Итак, короткое резюме решения проблемы:
1. Как и предполагалось, воссоздание индексов решило проблему.
2. Неправильные количества была только половина проблемы - аналогичная проблема наблюдалась и со себестоимостями, так что пришлось переиндексировать и Т 5802. Тут один индекс так и не удалось восстановить - сделал три попытки и каждый раз сервер сваливался.
3. Манипуляции с индексами либо импорт из fob'a таблиц вызвал побочный эффект - сбились права пользователей на это таблицы, пришлось синхронизировать. Само по себе это не проблема, проблема в том, что это выяснилось только с утра, когда все приступили к работе...

[igork-9y]

Выступлю в роли некропостера:
Столкнулся с аналогично проблемой совершенно случайным образом: обновили клиента до версии 4.0 SP3 (в планах перехать на sql 2008R2 + терминальный доступ основан на Windows 7). При запуске задания Коррекция с/с (R795) на некоторых товарах уходил в рекурсию (создавал в Т5802 одинаковые неправильные записи типом коррекция). Заитересовавшись подобной необычной ошибкой начал разбираться:
Первое с чем я столкнулся это необычное обновление переменной AverageCostLCY в F30 - оно обновлялось не во всех товарах (в каких то обновлялось правильно, в каких то не правильно, в каких то вообще не обновлялось), по которым существовали остатки. После непродолжительной медитации над кодом кодеюнита 5804 выяснилось:

CALCSUMS("Invoiced Quantity","Cost Amount (Actual)","Cost Amount (Actual) (ACY)");
AverageQty := "Invoiced Quantity";
AverageCost := "Cost Amount (Actual)";
AverageCostACY := "Cost Amount (Actual) (ACY)";

nicht arbeiten вообще.

При этом, расчет этих переменных в цикле а-ля

IF FIND('-') THEN
REPEAT
MESSAGE('%1_________%2_________%3_________%4',"Item No.","Invoiced Quantity",
"Cost Amount (Actual)","Cost Amount (Actual) (ACY)");
AverageQty +="Invoiced Quantity";
AverageCost +="Cost Amount (Actual)";
AverageCostACY +="Cost Amount (Actual) (ACY)";
UNTIL NEXT = 0;

прекрасно работало.
Долго думал, полез сюда подглядеть - ошибку с не корректным расчетом переменных на форме решил путем пересоздания ключей (благо таблички 32 и 5802 относительно не большие).
И вот что удивительное: решилась проблема с рекурсией и, как выяснилось, по части позиций с/с была расчитана некорректно.
Вопрос: кто нибудь когда-нибудь с подобным сталкивался? Может Microsoft что то пишет по этому поводу?

Переход был сделан с версии 3.7 на 4.0SP3, версия sql-сервера Microsoft SQL Server 2000 - 8.00.818 (Intel X86) May 31 2003 16:08:15 Copyright (c) 1988-2003 Microsoft Corporation Standard Edition on Windows NT 5.0 (Build 2195: Service Pack 4)

[Sancho]

Цитата:

Сообщение от igork-9y

...создавал в Т5802 одинаковые неправильные записи типом коррекция...

коррекция или округление?
если округление, то с таким "сталкивался".

[igork-9y]

Цитата:

Сообщение от Sancho

Цитата:

Сообщение от igork-9y

...создавал в Т5802 одинаковые неправильные записи типом коррекция...

коррекция или округление?
если округление, то с таким "сталкивался".

Запись создавалась с Adjustment = True - вот что имел в виду. Сейчас развлекусь восстановлением позачерашнего backup'а и выложу создаваемые записи в 5802.
Еще один вопрос - есть ли возможность пересоздать все индексы в БД? "Меня терзают смутные сомнения"(с), что индексы накрылись не только в таблицах 32 и 5802.

[alexb_imported]

Цитата:

Сообщение от igork-9y

Еще один вопрос - есть ли возможность пересоздать все индексы в БД?

Либо руками в каждой таблице деактивировать а потом опять активировать все вторичные ключи, либо написать код и сделать то же самое в коде, используя Rec-variable для таблицы "KEY"

[igork-9y]

Цитата:

Сообщение от AlexB

Цитата:

Сообщение от igork-9y

Еще один вопрос - есть ли возможность пересоздать все индексы в БД?

Либо руками в каждой таблице деактивировать а потом опять активировать все вторичные ключи, либо написать код и сделать то же самое в коде, используя Rec-variable для таблицы "KEY"

Спасибо, попробую что нибудь накодить ибо править приходится 11 БД.

[igork-9y]

Восстановил backup. Собственно что получилось:
1. Создавалась запись, приводящая к уходу в рекурсию (страница файла вложения "Запись в 5802 (рекурсия)"). Мое мнение, причины этого - неправильный расчет переменных в кодеюнитах 5895 (5804 и пр.) вследствии операций с упавшими ключами.
2. Переменная AverageCostLCY в форме 30 показывала полную ересь (см страницы файла вложение "Записи в 5802 до учета акта" и "Карточка ТМЦ до обн. ключей"). Причины проблемы аналогичны - расчет сумм не по первичному ключу приводит к ошибкам.
3. После пересоздания ключей - все нормально.(см. "Карточка ТМЦ после обн. ключей").

Причины падения ключей мне не ясны и совет могу дать только один:
Пересоздавайте все не первичные ключи при обновлении клиента с версии 3.7 до 4.0 SP3.

[igork-9y]

Странно, не вижу прикрепленного файла