Страница 1 из 1
Добавлено: 06 Октябрь 2004, 9:50
Гость
Здравствуйте!
Обстановка C55H, ШВС, WinXp SP1.
Столкнулся с такой ситуацией. В таблице TPS имеется ключ по строковому полю S20, которое объявлено с атрибутом OVER, флаг case sensitive не установлен. Локаль в проекте установлен на Windows. В browse по этому ключу используется наращиваемый локатор. Почему-то в определенный момент поиск стал чувствителен к регистру. В других таблицах все нормально. Build не помог. Выгрузил проблемную таблицу в текст, удалил tps, загрузил из текста. Все стало работать нормально. Есть подозрение, что это произошло после автоматической конвертации таблицы в словаре, но не уверен. Что бы это могло значить?
С уважением,
Вячеслав Черников support@finsoft.ryazan.ru
Написал: ClaList(2)
Добавлено: 06 Октябрь 2004, 9:51
Гость
Это значит, что есть еще рисковый народ, юзающий автоконвертацию словаря
Но если нравятся приключения - то почему бы и нет?
--
Best regards,
Vadym mailto:
vadim@softcreator.com
ICQ:
82308757
Написал: ClaList(2)
Добавлено: 06 Октябрь 2004, 9:53
Гость
О! Наш человек! А нашим людям читать доку религия не позволяет...
)
Collating Sequences
Changing Collating Sequence
Changing the collation sequence on a Clarion 2.003 or earlier TopSpeed file (by changing .ENV file or OEM flag) corrupts the file.
This is no longer true, because the collating seqence for the file is now stored within the file. This change is fully backward compatible. Old files continue to work as before and new files are accessible by older programs.
To add the collating sequence information to an existing file, simply do a full build on the file:
SEND(file,'FULLBUILD=on')
BUILD(file)
The collating sequence for a TopSpeed file is established when the table is created or a full build is performed. Therefore the OEM flag is only significant at the creation of the file or on a full build.
Any application that uses an incorrect sequence (due to an incompatible .ENV file) to access a file may get unpredictable results, but will not corrupt the data.
Сергей -
chusha@mail333.com ;
chusha@hotbox.ru
Написал: ClaList(2)
Добавлено: 06 Октябрь 2004, 12:56
Гость
OVER и автоконвертация ИМХО вещи несовместимые. А если OVER еще и в ключевом поле... ;-(
WBR,
Nick Tsigouro mailto:
nick@arsis.ru
Написал: ClaList(2)
Добавлено: 06 Октябрь 2004, 14:46
Гость
Я до сих пор юзал автоконвертацию без проблем.
Правда, в основном, на файлах DAT с OEM. В TPS были проблемы при автоконвертации после изменения размерности DECIMAL-полей.
Проблем с сортировкой STRING-ов и локаторами не было.
Ну, теперь для перестраховки придется ручками править созданные словарем программки-конверторы.
Александр.
Написал: ClaList(2)
Добавлено: 06 Октябрь 2004, 15:26
Гость
Но если нравятся приключения - то почему бы и нет?
В принципе, есть два вида конвертации - для внутреннего билда и для внешнего билда. В первом случае (процесс разработки и тестирования) удобно пользоватья автоконвертацией и отказываться от этой возможности очень бы не хотелось. Второй случай - тема отдельного разговора.
О! Наш человек! А нашим людям читать доку религия не позволяет...
)
Не, доку я перечитываю регулярно, а тут еще между строк нужно
Впрочем, ты прав. Вопрос снимается переиндексацией с FULLBUILD.
Спасибо.
OVER и автоконвертация ИМХО вещи несовместимые. А если OVER еще и в ключевом поле... ;-(
Дело не в OVER. Аналогичная ситуация и с обычными строковыми полями в ключах.
Лечится последующей переиндексацией с флагом FULLBUILD, как подсказал Сергей.
С уважением,
Вячеслав Черников
Написал: ClaList(2)
Добавлено: 07 Октябрь 2004, 9:57
Гость
Ну, теперь для перестраховки придется ручками править созданные словарем программки-конверторы.
Ну их то всегда полезно отсматривать, но речь не про них. Они все коректно делаают. Речь про брауз из словаря файла старой структуры, когда преобразование формата делается совершенно неконтроллируемо по дефолту на основании старого заголовка и нового описания.
WBR,
Nick Tsigouro
Написал: ClaList(2)