glaz58
Спасибо, что попытались помочь, но результат тот же, что со скобками, что без скобок. Упорно включает в суммирование строки, где Index=1. Придётся делать перенос поля из detail в Group footer calculate - Sum и делить на 2. Делить на 2 - потому что при переносе поля из Detail, которых 2 - Detail1 и Detail2 при суммировании в Group Footer результат удваивает.

Какое отношение отчёт имеет к запросу, и вообще при чём тут футеры и прочее - науке неизвестно
Не имея воспроизводимого примера, помочь тебе нет никакой возможности.
А набросать десяток команд создающих нужные курсоры, наполняющие их тестовыми данными и потом делающие этот самый запрос тебе лень - ну а нам то и подавно

Igor Korolyov
Ничего удивительного - если делать индексные ключи "неопределённого" размера, то рано или поздно получим эту ошибку. В хелпе есть целый раздел...

А еще в хелпе написано, а точнее, не написано, что STR() может создать строку длиной, отличной от указанной.

Да, там описываются ситуации, когда функция возвращает "string of asterisk", но при этом не уточняется, какой именно длины будет эта строка звездочек.
Более того, в одном из абзацев пишется, что если результат преобразования будет меньшей длины, чем указано, то строка будет дополнена пробелами до требуемой длины.

Но вот оказалось, что варианта со звездочками это правило не касается - при переполнении строка звездочек получается следующей длины в зависимости от желаемой длины результата:

Именно поэтому я был удивлен, когда нормально работающая чужая прога "вдруг" свалилась после того, как одной из таблиц сделали безобидный, на первый взгляд, ZAP, а ввести первую запись никак не удавалось.

Тогда и выяснилось, что "звездная строка", получающаяся при вычислении выражения:
имеет длину 4 вместо ожидающихся 10.



Исправлено 2 раз(а). Последнее : akvvohinc, 20.10.21 05:46

Вместо запроса select придётся делать репорт, в котором в Group footer суммировать поле. Только когда полосы detail две, а не одна, сумма по полю удваивается.

Цитата:

Вместо запроса select придётся делать репорт...

Думаю, не многим приходилось сталкиваться с такой альтернативой.

akvvohinc
Тогда и выяснилось, что "звездная строка", получающаяся при вычислении выражения:

STR(CTOBIN(SPACE(4)))

имеет длину 4 вместо ожидающихся 10.

Какая разница какую длину она имеет, если это в любом случае некорректное значение?
Даже если бы это число "упаковалось" в экспоненциальную нотацию, как это происходит при выводе на экран выражения CTOBIN(SPACE(4), ну или как произойдёт если "подправить" выражение на STR(CTOBIN(SPACE(4))+0.0) то в качестве индекса такое обрезанное значение совершенно неприемлемо.

Т.е. изначально в этом коде (создания индекса) ошибка - даже если не задаваться вопросом: аназачем переводить 4-символьную строку в 10-символьную для целей индексации (люди для оптимизации делают ровно наоборот - "упаковывают" данные, а тут раздувают изначально компактное представление).

Цитата:

Какая разница какую длину она имеет, если это в любом случае некорректное значение?

В моем случае значение имело, так как этот тег, как выяснилось, вообще не использовался.
Да и некорректного значения там не должно было быть - в поле записывался результат выражения BINTOC(i), где i менялся от 1, то есть это был "упакованный код" - наследие Доса, где не было типа I, но требовалась компактность.

Igor Korolyov
аназачем переводить 4-символьную строку в 10-символьную для целей индексации

Этого я уже не узнаю - программа чужая, и автор давно "потерялся".
Более того, на самом деле там было 4 слагаемых однотипных поля C(4), но лишь над первым производились эти манипуляции.
Я сначала просто оставил "имя поля" вместо этого выражения, а потом и вовсе удалил тег, когда выяснилось, что к нему нет обращения.



Исправлено 4 раз(а). Последнее : akvvohinc, 23.10.21 01:58