romano501 Junior Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Приложение на Delphi XE с использованием FIBPlus 7.3.   База данных в кодировке WIN1251.   Возникла потребность обеспечить работу в программе для пользователей грузии.   Решением было создать базу в UTF8, а в приложении менять Charset подключения к БД.   Для этого была создана БД с аналогичной структурой в кодировке UTF8.   Я расчитывал на то, что меняя DataBase.ConectParams.Charset c WIN1251 на UFT8 я смогу отрывать неUNICODE и UNICODE версию базы.   Но когда я делаю DataSet.Open из базы с кодировкой UFT8 выдается ошибка:   > Type mismatch for field 'NAME', expecting: Stri ng actual: WideString.   Тип поля NAME VARCHAR(40), к примеру.   Это значит что нужно удалить все String-поля во всех DataSet.FieldsEditors и заново их добавить, только после этого DataSets будут открываться.   Что значительно усложняет дело. Значит не получится из одного и того же исходного кода скомпилировать приложение, которое будет работать как с Unicode и неUnicode базой.   Подскажите, есть ли выход из этой ситуации? Как можно сделать чтобы одна версия исходного кода позволяла работать с базой в неUnicode и Unicode без перекомпиляции?   Суппорт Devrace.com морозится уже неделю Всего записей: 137 | Зарегистр. 24-03-2007 | Отправлено: 12:11 11-04-2013

romano501 Junior Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Нельзя не добавлять. В проекте порядка 70 форм, Columns используются как в Гридах, так и в коде Всего записей: 137 | Зарегистр. 24-03-2007 | Отправлено: 13:01 11-04-2013

romano501 Junior Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Сам конечно же Ну книжечки по Delphi еще когда-то давно помогли   Цитата: Гридам совершенно параллельно статические или динамические TField'ы. Ну как параллельно, если в Field-е определено форматирование, заголовок, ширина и причие няшечки? Всего записей: 137 | Зарегистр. 24-03-2007 | Отправлено: 14:11 11-04-2013

romano501 Junior Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Проект в принцпе Unicode-ready, просто клиентских установок дофига чтобы всех переводить.   Думал сделать отдельный билд для грузина и отпустить его восвояси.   Цитата: Ужс. Это в каких книжечках написано делать так, как у тебя? Не понимаю сарказма. Что здесь ужасного? Как любой dbaware-control будет отображать Field, если он не добавлен в DataSet.Fields ?   Добавлено: Цитата: А что мешает то же делать в коде? Ну типа визуальная разработка и все такое... А еще репозиторий полей FibPlus Всего записей: 137 | Зарегистр. 24-03-2007 | Отправлено: 14:26 11-04-2013

romano501 Junior Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: DataSet.Fields[0].DisplayLabel,  DataSet.Fields[0].DisplayWidth и прочие няшечки. Ну да, для 30 датасетов с 10-20-30 и больше полями прописывать все это и многое другое руками в коде - то еще веселье... Всего записей: 137 | Зарегистр. 24-03-2007 | Отправлено: 16:50 11-04-2013 | Исправлено: romano501, 07:09 12-04-2013

romano501 Junior Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору delover TFIBStringField было изначально, но когда открываешь UNICODE-базу, то строковое поле становится TFIBWideStringField   Преобразования типа Цитата: varOleStr:   S := Copy(WideString(Pointer(V.VOleStr)), 1, MaxInt); у меня в проектах не используется.   А что останавливало от перевода проекта полностью на UNICODE: 1) программа используется только для славянских пользователей. Это один пользователь из грузии захотел чтоб по грузински все писалось и я попробовал реализовать поддержку, не ожидал что будет затык 2) не хочется чтобы объем БД становился больше 3) даже если выпустить новую версию, переведя все строковые фиелды на WideString нужно вручную каждую базу каждого клиента переконвертировать. По времени это достаточно долго.   Проекту изначально не нужен был Unicode.   delover Цитата: я выбрал другой путь - мне так удобнее. Всмысле определить фиелдсы в датасетах на этапе дизайна форм/датамодуля?   Всего записей: 137 | Зарегистр. 24-03-2007 | Отправлено: 20:37 11-04-2013

romano501 Junior Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору ... и этот проект не исключение Всего записей: 137 | Зарегистр. 24-03-2007 | Отправлено: 20:46 11-04-2013

miwa Full Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: ... и этот проект не исключение Ну так же ж отлично Я не знаю специфики проекта, поэтому решение в лоб Код:   for c := 0 to self.ComponentCount do   if self.Components[c] is TpFIBDataSet then     with (self.Components[c] as TpFIBDataSet) do       begin       DefaultFormat := ...;       AutoCommit := ...;       for j := 0 to FieldCount do         case Fields[j].DataType of             ...         end;     end;   Что-то типа такого. Пишется один раз в одном месте. Удобно, правильно, понятно, быстро.   Цитата: не хочется чтобы объем БД становился больше   Не уверен, что кто-то заметит разницу.   Цитата: даже если выпустить новую версию, переведя все строковые фиелды на WideString нужно вручную каждую базу каждого клиента переконвертировать. Зачем? Один раз пишется и тестируется скрипт, котрый все делает во время технического перерыва. И если база не используется 24х7х365 - то хоть всю ночь. Всего записей: 455 | Зарегистр. 10-10-2004 | Отправлено: 01:12 12-04-2013 | Исправлено: miwa, 01:12 12-04-2013

romano501 Junior Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору miwa Все DataSets находятся в DataModule. Цикл ни к чему, т.к. есть DataSet.DafaultFormats. И у каждого Field есть свой собственный атрибут: DisplayLabel, DisplayWidth, не говоря уже о том, что у некоторых полей есть обработчик GetText, SetText и тому подобные, обработчик проверки условия и еще некоторые детали. И вообще, нереально для CRUD-приложения, напичканого различными DBControls, писать весь код руками, вместо определения DataSet.FieldsDefs в DesignTime. Согласен что для какой-то задачи обработки данных, где нет активного взаимодействия с пользователем, динамическая работа с Fields будет более оправдана. У меня есть в проекте DataSet без Fields. Это отчетная форма, где каждый запрос имеет различный состав полей. И работа с таким DataSet динамически - довольно неудобно, но приходится, что делать.   Код fdsEmployeeID.Value, fdsEmployeeNAME.Value гораздо информативнее, чем fdsEmployee.Fields[0].Value и fdsEmployeeю.Fields[1].Value.   Это еще надо помнить какой номер у каждого поля для каждого DataSet - да ну нах. Ну еще контроль во время компиляции - тоже немаловажно. Всего записей: 137 | Зарегистр. 24-03-2007 | Отправлено: 07:27 12-04-2013

romano501 Junior Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору OXDBA   Код:   const   fnEmployeeId = 'ID'; ....   fdsEmployee.FieldByName(fnEmployeeId).asInteger   Да, это вполне рабочая конструкция. Используется в унифицированной форме-справочнике для стандартных полей ID, NAME, NOTE и некоторых других.   Но при этом я подстрахован уже определенными в DataSet.Fields именами полей.   Код: ALTER TABLE EMPLOYEEE ALTER NAME TYPE VARCHAR(128) После изменения длины строкового поля, либо домена достаточно переоткрыть датасет в Design-time чтобы в DataSet.FieldsDefs подставилась новая длина поля и все. Цитата: Тогда уж сразу drop table FIB$DATASETS_INFO. Ну это ты, батенька, уже во все тяжкие бросаешься.     Предлагаю все таки вернуться к моему вопросу, а не обсуждению стилей программирования. OXDBA, твой посыл понятен. Работать с наборами полей датасетов динамически. К сведению принято. Но этот вариант мне не походит.     Всего записей: 137 | Зарегистр. 24-03-2007 | Отправлено: 12:12 12-04-2013

miwa Full Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Ну да, для 30 датасетов с 10-20-30 и больше полями прописывать все это и многое другое руками в коде - то еще веселье...   Цитата: После изменения длины строкового поля, либо домена достаточно переоткрыть датасет в Design-time чтобы в DataSet.FieldsDefs подставилась новая длина поля и все.     Таки датасет один, или 30?     Цитата: Все DataSets находятся в DataModule.   Вообще все? Со всего приложения? На екране место еще не закончилось? А что будет, если закончится?   Цитата: Предлагаю все таки вернуться к моему вопросу, а не обсуждению стилей программирования.   Тогда предлагаю полный переход на юникод. Потому что сегодня грузинский клиент что-то захотел, завтра казахский будет ругаться, что его 1251 не совпадает с вашей, послезавтра турки захотят вашу программу, а через месяц отечественный заказчик откроет представительство в Китае. Глобализация Всего записей: 455 | Зарегистр. 10-10-2004 | Отправлено: 13:10 12-04-2013

romano501 Junior Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Датасетов много, 30 это я обозначил примерный объем, пока в одном DataModule помещаются   Итак, вариант №2 - полный переход на UNICODE - принято Всего записей: 137 | Зарегистр. 24-03-2007 | Отправлено: 13:17 12-04-2013

Страницы: 1 2

Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Работа с неUNICODE и UNICODE базами одного Delphi-приложения

Переход по форумам  Закладки   » Компьютеры Цифровое изображение Программы Microsoft Windows UNIX Другие OS Hardware В помощь сисадмину Прикладное программирование Игры Форумные игры   » Интернет Web-программирование В помощь вебмастеру Графика Хостинг Зацените-ка!   » Тематические Ikonboard v.2 Ikonboard v.3 Invision Board Другие форумы PHP-Nuke и другие порталы Мобила   » Общие Спорт Флейм Темы по региональным встречам Музыка и Кино Юмор Литература и Живопись   » Ru.Board Новости Помощь по форуму   » Андеграунд eBookz Варезник Раздачи и акции Мобильный варезник Андеграунд Игры и фильмы   » Специальные Тестирование