Глюк FlowField?

[rmv]

Цитата:

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

1. Key = "Document No.,No.,Entry Type,Quantity", SumIndexField = Quantity
2. Calcformula = -Sum("Ledger Entry".Quantity WHERE (Document No.=FIELD(Document No.),No.=FIELD(No.),Entry Type=FILTER(Transfer|Negative Adjmt.),Quantity=FILTER(<0)))
3. Нет. Для строк есть своя отдельная таблица, т.е. есть таблицы Header, Line, Ledger Entry.
4. а где мне его посмотреть?

По пункту 4 - можно нужно смотреть дизайн таблицы в Enterprise Manager или MSSMS не знаю что у вас там.
Вам все же придется перестроить свое решение, и отказаться от использования Quantity в ключе.
Постараюсь объяснить в чем проблема как можно более понятным языком.
Дело в том, что для поддержки SIFT в версии sql до 5.0 Навижн использует доп. таблицы и триггера на таблицах в SIFT полями.
На каждый ключ с с SIFT полями существует своя таблица, состав полей таблицы:
1. bucket - условно говоря уровень агрегации, количество уникальных bucket соотвествует числу галочек, показываемых на форме Sift Level List
2. Набор полей, составляющих ключ. По нему же составлен первичный ключ таблицы. "Document No.,No.,Entry Type,Quantity" в вашем случае
3. Набор полей, содержащий вычисляемые поля. Quantity в вашем случае
Триггер на вставку в это таблицу (расчет сифтов) генерится при редизайне таблицы из Нава. Опуская технические детали, можно сказать что триггер работает с двумя виртуальными таблицами - deleted (удаленные записи), inserted (вставленные записи). C вставкой и удалением записей надеюсь понятно, при модификации таблица deleted содержит запись до изменения, inserted после изменения.
Пока не страшно? Дальше будет веселее.
Опуская некоторые детали в части bucket в общем случае обновление сифтов выглядет как изменение записи если она по составу первичного ключа уже есть в базе, при этом вычисляемые поля считаются "Старое Значение В Базе" - "Значение В Таблице deleted" + "Значение в Таблице Inserted":
1. Навижн обновляет данные в таблицы только если измененились какие либо-из полей, входящие в ключ, либо в состав вычисляемых полей.
2. Навижн пытается проапдейтить запись, выполнив "Старое Значение В Базе" - "Значение В Таблице deleted" для полей PK, если не получилось (записей с такими полями PK нет в базе),
то идет вставка записи поля PK, в значениях вычисляемых полей - (минус) "Значение В Таблице deleted".
3. Навижн пытается проапдейтить запись, выполнив "Старое Значение В Базе" + "Значение В Таблице inserted" для полей PK, если не получилось (записей с такими полями PK нет в базе), то идет вставка записи поля PK, в значениях вычисляемых полей + "Значение В Таблице inserted".

В при смене Quantity с -15 на -10 Навижн ступил и вставил 2 доп. записи вместо обновления одной:
Было:
В сифт таблице запись Док,Но,Negative, -15, -15
Первичный ключ Док,Но,Negative, -15
Вычисляемое поле -15
Стало:
Первичный ключ Док,Но,Negative, -10
Вычисляемое поле -10

Логика похоже следущая:
1. Пытаемся обновить ключ Док,Но,Negative, -10 (здесь уже новое значение!). Не получилось. Вставляем Док,Но,Negative, -10, +15 как вычисляемое поле.
2. Без попытки обновления ключа Док,Но,Negative, -10 или -15 (обе записи есть в базе). Вставляем Док,Но,Negative, -10, -10 как вычисляемое поле.
Все привет Нав. Вместо одной записи в базе теперь три.

Рекомендую пересмотреть архитектуру решения. Boolean поле Open еще с трудом можно оправдать сложностью поддержки (ну иль ленью), то Positive уже вычислить труда совсем не составит.