Добрый день! Подскажите, плиз, как бороться с таким глюком.
Следующий запрос
выдаёт
Всё хорошо!
Но если просто добавить связь с другой таблицей (её поля для краткости не отображаем), то получаем

Конечно, если поставить iif(empty(N.TYPE) ,'000' ,N.TYPE), то всё будет хорошо. Но прикол в том, что: 1) это готовое ПО и менять ничего нельзя;
2) в других подразделениях этого глюка нет.

Подскажите, можно ли устранить этот глюк изменением каких-нибудь настроек?

Aleksey-K1. Ну если НИЧЕГО менять в запросе нельзя, какой совет вы хотите получить ?!
2. Какая версия VFP ?

1.Всё дело в том, что в других подразделениях этого глюка нет. Значит дело в настройках. Где менять (или искать)?
2. Visual FoxPro 7.0.

ВладимирМ
Если первой попалась запись у которой empty(N.TYPE)=.T., то значение поля будет '0', т.е. C(1). Если же первой попалась запись у которой empty(N.TYPE)=.F., то значение поля будет N.TYPE и размерность будет равна размерности поля N.TYPE.
...
Ну, или в том подразделении где есть глюк придется как-то физически перестроить таблицы, так, чтобы первой попадалась запись у которой empty(N.TYPE)=.F. Но это временная мера и без гарантий, что в будущем у другого подразделения опять проявиться тот же глюк.

Оставил все записи с empty(N.TYPE)=.F. и все N.TYPE со значениями C(3). Результат тот же.
Обращаю внимание - глюк появляется, когда есть связь с другой таблицей.

Владимир СА
Происходит связь с другой таблицей через WHERE, а ничего из таблицы SPLAT неберем. Зачем соединяемся с таблицей SPLAT ???

Я указывал, что поля SPLAT для краткости не отображаем. Если нравиться, можно добавить в запрос поле SPLAT.NAME C(60).
Владимир СА
2. Перечислите поля таблицы SPLAT и их размерности.

Их довольно много, но поля TYPE там нет, если Вы это имели ввиду.

Aleksey-K2. Какая версия VFP ?
Кстати, проверили и на FoxPro 2.6 for DOS - тот же глюк.

Владимир САТогда в запрос поставьте как предлагал ВладимирМ :
iif(empty(N.TYPE) ,PADR('0',LEN(N.TYPE)),N.TYPE) as TYPE1
и сообщите результат.
Это сработало.
Но я повторяю, что ничего менять в ПО мы не можем. Можем дать только
предложения.
Обнаружили ещё одну интересную вещь - всё зависит от значений поля KOD - для некоторых значений работает нормально, а для некоторых нет. Т.е. если оставить в таблице OBJECT значения с одним конкретным значением KOD, то для одних значений возвращает нормально, а для других глючит. Причём другие строки должны быть не просто удалены, но и выполнен PACK.
Интересно...
Будем искать...

Наконец-то нашли что-то конкретное - работает нормально, если число записей в OBJECT не превышает 653.
Подскажите кто-нибудь - это решаемо?

KomissarХм... Где-то я эти названия полей уже видел... Уж не налоговая ли инспекция? ;-)
Гениально, Холмс! Как Вы догадались?
Komissar
Если ДА, то КОМУ Вы направляете предложения? Буду дико удивлен, если Вы назовете имя "Владимир Иванович"!!!
Нет, не ему!

ВладимирМДа при чем здесь количество полей.
Не полей - записей .
Этот вопрос снимается - попробовали на таблицах с меньшим числом полей - этот эффект стал проявляться на количестве записей около 350. Проанализировать не было времени, но скорей всего зависит от количества уникальных значений поля OBJECT.KOD.
ВладимирМ
Получим описанный эффект. Как исправить не меняя сам запрос? Ну, в данном конкретном случае, надо уйти от связи вида один-ко-многим. Т.е. не должно быть ситуации, когда одной записи из таблицы cur1 соответсвует несколько записей из таблицы cur2. Но это частное решение и без каких-либо гарантий.
Т.е. весь вопрос в том, какие именно записи будут использованы командой Select-SQL для формировании структуры таблицы.

От связи один-ко-многим тут не уйти...
Вообще-то интересно, когда результат запроса зависит от порядка записей в таблице.
Ладно, давайте закончим этот топик.

И самое интересное в конце - оцените глубину мысли разработчика:
в полном тексте запроса в предикате WHERE стоит and !empty(n.type).
Т.е. примерно так
SELECT N.KOD , N.TYPE, iif(empty(N.TYPE) ,'0' ,N.TYPE) TYPE;
FROM OBJECT N, SPLAT S;
WHERE N.KOD=S.KOD and !empty(n.type) .
Ну, в общем, спасибо всем за обсуждение!