"Column name must be unique" для типов данных GROU

[Гость]

Здравствуйте, Clalist

Тестировал в C55 ABC, C6.1 ABC
Кажется, когда-то эту проблему хорошо комментировал Олег Руденко.

При объявлении одинаковых полей в двух GROUP или в двух QUEUE, в которых не указан префикс, получаем "Column name must be unique". Ситуация касается также объявления таким образом полей внутри таблицы в DCT. Только разница в том, что в APP при описании таких переменных выдается предупреждение (видимо шаблон не пропускает), а в DCT при описании никаких сообщений не выдается.
Но далее встречаем проблемы. Операция импорта из TXD, созданного по этому DCT, в любой другой DCT, вываливается в ошибку. Такую же ошибку получаем при операции Multi Table Import в этот DCT.

Например,

Код: Выделить всё

 MyFile
FILE,DRIVER('TOPSPEED'),NAME(GLOVAR:NameMyFile),PRE(MF),CREATE,THREAD
 Record                   RECORD
 GROUP_1   GROUP
 Name             STRING(20)
                      END
 GROUP_2   GROUP
 Name             STRING(20)
                      END
                                 END
               END

Описать такой файл в DCT среда позволила, приложение скомпилировал, и компилятор не ругнулся. Но, не выполняются вышеизложенные операции.
Более того, среда не позволяет потом редактировать такие поля.

Это что у велосипедистов политика такая? Почему бы не позволить описание такого вида файлов? Было бы очень удобно. Решается ли это в С6?

С уважением, Семен Попов

PS: Извините, что предыдущий раз немного некорректно поставил вопрос.
Написал: ClaList(2)

[Гость]

Не, это не политика, это - ошибка разработчиков оболочки. Хотя, их можно понять!
Дело вот в чем:

• - компилятор воспринимает обьявление структуры файла явно и, как следствие, сразу-же в СВОЕЙ таблице меток переменных (времени компиляции) делает однозначное соответствие меток MF:GROUP_1.Name и MF:GROUP_2.Name с их смещениями относительно начала структуры. Поэтому и в программе ВСЕ ЯВНЫЕ обращения к этим полям буду работать правильно.
  - все утилиты оболочки типа импорта/экспорта, просмотра и редактирования файлов данных работают НЕ С ЯВНЫМИ метками полей, а с той информацией, которая содержится в дескрипторе-описателе структуры файла. А там метки полей имеют ТОЛЬКО одну-единственную ссылку на родителя - префикс всего файла! Т.е. в описателе вышеприведенного файла имеем ДВА поля с ОДИНАКОВЫМИ МЕТКАМИ: MF:NAME!

Все! Больше никакой другой информации там нет.
А, учитывая то, что ВСЕ утилиты оболочки для разбора структуры файла используют ОДИН класс из RTL Клариона, а так-же, учитывая, что этот класс НЕ УМЕЕТ правильно обрабатывать такие ситуации (да и другие подобные), то становится понятна причина глюков этих утилит!
Кстати, "глючность" этого класса и заставила меня при разработке DynaLib отказаться от его использования и полностью заново писать ядро разбора структур типа GROUP/CLASS/QUEUE/FILE/VIEW.

Решается ли это в С6?

Часть "глюков" вышеназванного класса была исправлена и несколько расширен его функционал. Но не полностью!
И если утилиты оболочки по-прежнему при разборе структур полностью опираются на этот класс, то, скорее всего, подобные глюки присутствуют и в C61. Хотя сам я это не проверял.

=============================
С уважением, Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com
Библиотека DynaLib
http://dynalib.narod.ru


(Добавление)

Здравствуйте, Олег!

Спасибо за отзыв.
Получается, что выхода нет, и при описании файла лучше не стремиться использовать такой стиль.
И структуру, подобную этой,

Код: Выделить всё

 Adress FILE,DRIVER('TOPSPEED'),NAME(),PRE(ADR),CREATE,THREAD
 Record                   RECORD
 AdressReg   GROUP ! Адрес регистрации
...
Index                LONG
Country           STRING(40)
...
                        END
AdressFact   GROUP ! Адрес фактический
...
Index                LONG
Country           STRING(40)
...
                        END
                                 END
               END

лучше описывать примерно так:

Код: Выделить всё

 Adress FILE,DRIVER('TOPSPEED'),NAME(),PRE(ADR),CREATE,THREAD
 Record                   RECORD
 AdressReg   GROUP ! Адрес регистрации
...
ARIndex                LONG
ARCountry           STRING(40)
...
                        END
AdressFact   GROUP ! Адрес фактический
...
AFIndex                LONG
AFCountry           STRING(40)
...
                        END
                                 END
               END

Разбивку по группам все равно для наглядности оставляю.
Жалко, конечно, что это не реализовано.

С уважением, Семен Попов

Написал: ClaList(2)

[Гость]

Ну, я обычно всегда делаю по второму варианту.
На всякий случай!

Хотя, повторяю, и первый вариант будет работать В ПРОГРАММЕ правильно! Проблемы возможны ТОЛЬКО в cледующих случаях:
- использование внешних утилит, которые работают с данным файлом БЕЗ описания его структуры, а только по информации о структуре из заголовка файла.
Опять-же - НЕ ВСЕ! Информация о структуре из заголовка
ПОЗВОЛЯЕТ КОРРЕКТНО обрабатывать подобные варианты.
Поэтому, если утилита ПРАВИЛЬНО использует эту информацию, то проблем не должно быть!
- в самой программе, при использовании методов "глубокого присваивания" типа ADR1:Record :=: ADR:Record
Об этой ошибке (имхо) я уже как-то писал в этой рассылке (год или два назад). В этом случае не поможет даже назначение внутренним группам своих префиксов.
При этом ВСЕ одноименные поля из всех подгрупп первой структуры получат значения соответсвующих полей из ПОСЛЕДНЕЙ подгруппы второй структуры!
Не исправлена эта ошибка и в последнем релизе C61.
Хотя, опять-же, правильный код для реализации "глубокого присваивания", который учитывает и этот вариант, пишеться буквально за минуты.

=============================
С уважением, Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com
Библиотека DynaLib
http://dynalib.narod.ru

Написал: ClaList(2)