Сделала. browse выдает все значения верные, но вот при выводе в ехсеl происходит след ошибка. если значение attrval.vdouble есть то выводится информация верно, а если там ничего не должно быть то выводится информация по предыдущему значению attrval.vdouble, т.е как будто значение attrval.vdouble не обнуляется(( при переходе к след позиции katmc
if (IsValid(tnATTRVAL)) {
if(attrval.vdouble<>1 or attrval.vdouble<>2 or attrval.vdouble<>3 or
attrval.vdouble<>11 or attrval.vdouble<>12 or attrval.vdouble<>13)
then
xlSetCellStringValue('отстутствует',kol,2,kol,2);
else
xlSetCellStringValue(attrval.vdouble,kol,2,kol,2);
}
else
xlSetCellStringValue('полностью отстутствует',kol,2,kol,2);
Вообще, такие простые выборки гораздо быстрее делать SQL-запросами, а не интерфейсами. Если нужно под Excel - в конце добавить TO DBF.
А вот интересно, почему если для текущей родительской записи нет дочерних и читаем дочерние, то возвращается не default значение ('', 0, 0.0, 0h), а последнее валидное? Такое (как у korvanakorvana) раньше у меня было, но потом пропало и возвращаются именно значения по умолчанию. Нигде не написано какое должно быть поведение. Поэтому для себя я решил не ставить проверку по IsValid в таких случаях. Задавал вопрос ТП по уточнению данного нюанса - ничего внятного не услышал, они в программировании вообще не сильны ((
З.Ы. У меня подозрение, что для второго уровня дочерних записей (AttrNam) все работает как default (т.е. IsValid можно не ставить), а вот третий уровень (AttrVal) уже неопределенное поведение
В таких случаях желательно тогда говорить IsValidAll
Метод IsValidAll
Назначение
Возвращает логическую истину, если есть текущая позиция в узле iLeaf логиче-
ской таблицы. В случае отсутствия позиции нельзя вызывать позиционно зави-
симые модификаторы (update, delete, getNext, getPrev) – будет возвращен код
ошибки.
Речь не про IsValidAll. Хэлп я читал. Там вообще невнятно написано, я так и не врубился чем IsValid отличается от IsValidAll. По опыту: IsValidAll применим для именованных view. Попытка вызывать IsValid для той же view, вызовет ошибку компиляции.
Речь вообще-то шла о том можно ли читать из дочерних таблиц, если там нет записей. Т.е. что будет возвращено - мусор или дефолтное значение?
galover писал(а):Нигде не написано какое должно быть поведение. Поэтому для себя я решил не ставить проверку по IsValid в таких случаях.
Странное решение. Проверка нужна именно потому, что поведение непредсказуемо. Все-таки прикладной программист должен смотреть, получает он реальные данные, или этих данных нет, и к нему попадает мусор. Конечно, было бы неплохо перед передачей на прикладной уровень такой мусор обнулять, но с программиста это ответственности не снимает.
galover писал(а):У меня подозрение, что для второго уровня дочерних записей (AttrNam) все работает как default (т.е. IsValid можно не ставить), а вот третий уровень (AttrVal) уже неопределенное поведение
ATTRNAM - не дочерний уровень, для него нет "родительских" таблиц.
Странное решение. Проверка нужна именно потому, что поведение непредсказуемо. Все-таки прикладной программист должен смотреть, получает он реальные данные, или этих данных нет, и к нему попадает мусор. Конечно, было бы неплохо перед передачей на прикладной уровень такой мусор обнулять, но с программиста это ответственности не снимает.
Решение пришло по опыту, у меня возвращаются дефолтные значения. Поэтому при чтении, IsVAlid я не ставлю. Вот и все. Критерий истины - практика и опыт. Ответственность на мне, кто ж спорит. Был бы стандарт могли бы на него сослаться, а так только методом проб и ошибок.
ATTRNAM - не дочерний уровень, для него нет "родительских" таблиц.
имел в виду, что на нем есть ограничения по подцепке. Все что в подцепке справа - дочерний элемент
лично я IsValid не использую, давным давно были проблемы, теперь везде ставлю IsValidAll. Ну а неопределенное значение-есть неопределенное значение. Учитывая, что NULL-а не имеется, что же возвращать-то? Всегда желательно проверять в подобных случаях во избежание мусора. а в данном случае можно вообще ко вьюхе добавить ограничение
where ((...)) and isvalidall(tnattrval)
Alexander
ну тут тормоза будут на пустом месте, фильтр вообще тормозит. IsValid работает нормально, на именованных вьюхах только не работает. Вообще о таких нюансах могут только разработчики ядра рассказать. Беда в том, что нет стандарта на поведение (как, например в С++), который бы жестко фиксировал все нюансы - где неопределенное поведение, где исключение, а где дефолтное значение