|
|
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
Добрый день! Вне зависимости от настроек системы (и локализации системы), хочу хранить данные двух кодовых страниц - русский и немецкий. В голову пришла мысль только реализовать через текстовый файл. А есть ли какая БД (dbf, paradox или что-то еще), которая бы поддерживала это? Все данные на MSSQL, но нужна именно локальная база (и по возможности создавать стандартным экспортом этот файл). Проект на Делфи 7, в котором с юникодом как-то (по наблюдениям) прямо скажем никак. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2018, 13:28 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
Йо!Все данные на MSSQL, но нужна именно локальная база (и по возможности создавать стандартным экспортом этот файл). MS SQL Compact Edition тебе в руки. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2018, 13:29 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
Не пойдет, надо именно локальный файл. Данный файл будет на флэшке носить на три станции пользователь, который скопировать простой файл едва в состоянии... Одновременно это требование заказчика, если так его можно назвать. Большое спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2018, 13:40 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
Йо!Не пойдет, надо именно локальный файл. Это и есть локальный файл. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2018, 13:44 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
Знаю есть компоненты для прямой работы с Access, например, наверное с ним можно такое замутить. Как-то кажется, что MS SQL Compact Edition надо инсталлировать, туеву хучу файлов содержит. Просто так файл не скорировать, надо базу останавливать напрмер .... Опять же на другом компе надо еще подсунуть этот файл.... НО посмотрю, спасибо. Если есть другие решения, например с перекодировкой, то буду рад наводке. Поиск нуден только по ключу, если что и по русскому текстовому полю (полям). СПасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2018, 13:55 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
SQLite, Firebird Embedded, NexusDB (елси семёрку поддерживает ) в DBF есть много кодовых страниц, и русские и немецкие, но юникодной кажется нет. Хотя, если запустить DBF 7-й версии - но его кроме твоей программы хрен кто прочитает, формально там кажется в расширенном заголовке файла есть поле windows Codepage. Попробуй tdbf.sf.net Или просто на каждый язык по отдельному файлу. Йо!Проект на Делфи 7, в котором с юникодом как-то (по наблюдениям) прямо скажем никак. из коробки плохо коненчо, но сторонние компоненты есть VirtualTreeView, TNT Suite ( www.yunqa.de ), если остались исходники UniRed.sf.net - там тоже должно быть ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2018, 15:30 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
Йо!В голову пришла мысль только реализовать через текстовый файл. JSON или XML ? Они по стандарту в UTF-8 по умолчанию А чтобы целостность и размер - файл в ZIP'е держать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2018, 15:31 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
SQLite или JSON - попробуй въехать в Synopse mORMot, пока они не выкинули поддержку Delphi 7 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2018, 15:44 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
Йо!по возможности создавать стандартным экспортом этот файл Что такое "стандартный экспорт" в твоём понимании? Лично я понял, что стандартный экспорт, в данном случае, это экспорт средствами самого MSSQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2018, 16:00 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
В BDE Paradox можно назначать языковый драйвер для каждой таблицы, но делается это через Database Desktop, а он на 64-хразрядной винде не пашет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2018, 22:06 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
Насколько я знаю DataBase Desktop перестал работать только на последнем обновлении Win 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2018, 22:30 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
Йо!... Все данные на MSSQL, но нужна именно локальная база (и по возможности создавать стандартным экспортом этот файл). ... Неужели "стандартный экспорт" может создать что-то более-мене пригодное для дальнейшей работы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2018, 23:33 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
rgreatНасколько я знаю DataBase Desktop перестал работать только на последнем обновлении Win 10.А как починить не знаете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 00:38 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
Более старая винда в эмуляторе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 00:39 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
Интересует именно одна единственная таблица, но вот колонки разные... Основная масса - русские/английские и только две - немецкие. По ним, конечно, никаких индексов, поиск и прочих плюшек не надо, только получение значения поля по ключу. Можно организовать и двумя таблицами, но зачем таблицы с одинаковой сущностью и одинаковым количеством строк? Очень странно, что такая тривиальная проблема не имеет решения - по большом, любой продукт рассчитанный на какую-либо локализацию должен поддерживать одновременно несколько языков. Насколько оправдано с решением с кодировкой и раскодировкой текста в двоичном коде (коды символов) и хранени в таком виде в базе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 13:15 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
Йо!такая тривиальная проблема не имеет решения Тебе уже предложили несколько решений. Выбирай. Только не используй BDE - это труп, и даже не ходячий. Йо!любой продукт рассчитанный на какую-либо локализацию должен поддерживать одновременно несколько языков. По очереди, а не одновременно. Unicode в VCL (стандартном) появился только в D2009. Йо!только получение значения поля по ключу. Может быть тебе тогда и не нужно таблицу? Держи например ZIP-файл в памяти. Ключ и солбец задают имя файла, достаешь его и используешь. А также XML и JSON, но для такой простой структуры может быть излишне. Никто не знает какого размера твои данные, как часто они читаются, вот только что узнали - что количество колонок разное для разных языков.... Только ты знашеь, что хорошо ляжет на твою задачу, а что нет. Вариантов много - пробуй и выбирай. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 15:26 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
чччД выфыфыНеужели "стандартный экспорт" MS SQL может создать что-то более-мене пригодное для дальнейшей работы? ....ну например XML, останется его тоьлко зипануть и можно внутрь EXE класть в ресурсы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 15:27 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
Никого секрета нет, данные - таблица клиентов. Стандартные поля - номер внутренний, название, адрес и т.д. - и эта вся информация на русском языке. Помимо всего прочего, есть название и адрес на НЕМЕЦКОМ языке, и они должны быть написаны корректно - с умляутами. Получается, вне зависимости от локализации Windows надо, чтобы было все именно так и отражено - русское на русском, немецкое на немецком. В данный момент около 10 тысяч записей. Существующий файл - текстовый к юникоде - где каждая ячейка представлена отдельной строкой и при загрузке парсится в грид начинает задыхаться, это получается 10 000 записей помножить на 20 полей - 200 000 строк, однако. Плюс ко всему, нет нормального поиска, например (и быстрого). Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 16:39 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
SQLite ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 17:10 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
!Йо... В данный момент около 10 тысяч записей. Существующий файл - текстовый к юникоде - где каждая ячейка представлена отдельной строкой и при загрузке парсится в грид начинает задыхаться, это получается 10 000 записей помножить на 20 полей - 200 000 строк, однако. Плюс ко всему, нет нормального поиска, например (и быстрого). ... Ну и оставь текстовый формат, только оптимизируй его. Что-нибудь вроде csv используй. Будет мгновенно грузиться. А поиск отдай на откуп системе отображения. Например, TcxGrd отлично ищет/фильтрует. Запитай такой грид собственным наследником от TcxCustomDataSet (там вручную кодить полторы строчки), вот и нет "проблемы". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 17:21 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
Меня смущает несколько моментов. И один из них - момент создания самого этого файла. Его создание - процесс тяжеловатый и долгий, на лету - напрягает. Приходится долго ждать, а делать надо раза три в час. Вставляю сначала структуру - псевдо матрица столбцы и кол-во строк, затем построчно один столбец, другой и т.д. Выгрузка в ДБФ, например, проходила бы не влет, но существенно быстрее. Но SCV наверное самое разумное решение сейчас - вышеописанную проблему решит, да еще и не надо все данные грузить сразу в грид (хотя с этим не уверен), что тоже немного напрягает (долго). Спасибо. По результатам всего вышеописанного посмотрю, все же, есть ли какие-то традиционные табличные решения (NexusDB, DBF 7) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 17:50 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
Йо!... И один из них - момент создания самого этого файла. ... Странная проблема. Сделай экспорт-утилиту сам, как твоя левая пятка пожелает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 18:00 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
!ЙоСуществующий файл - текстовый к юникоде - где каждая ячейка представлена отдельной строкой и при загрузке парсится в грид Вот в этом твой геморрой и есть. Ты перепутал объекты для хранения данных и объекты для показа данных пользователю, а это во многом противоположные вещи. У нас один уникум как-то умудрился для загрузки дерева из сервера на форму поставить невидимый VirtualTreeView ,в который элементы грузились подряд в один уровень, потом внутри дерева сортировались, потом переносились в основной видимый VTV. Работала эта схема на 60К записей секунд 20-40, в зависимости от процессора. Наткнулся я на это, когда в ini-файле с настройками эти самые настройки начали пропадать. Оказалось, что в ini-файл сбрасывался почти целиком SQL-запрос, и он в какой-то момент вылез за разрешенные Windows размеры ( то ли 32КБ на раздел, то ли 4 КБ на строку ) и - упс. Удивился, нашел кусок, за это отвечающий, убил его, - и получил те самые 20-40 секунд на открытие другого окна ( для формирования запроса окна-фильтры создавались, грузили свои настройки, и отрабатывали в невидимом режиме). Выкинул все это к лешему, написална коленке своё дерево из record'ов с указателями, подумал над запросом к серверу - чтобы строки уже правильно сортированные приходили, хотя это не критично - и в результате это место теперь проходит за 0,02 секунды вместо 20. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 19:10 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
!ЙоПлюс ко всему, нет нормального поиска, например (и быстрого). Если строки типа "ключ=значение, значение, значени, значение..." - то грузи их в TStringList, потом включай ему сортировку - и ищи на здоровье. Хоштя я не сильно люблю TStringList, но в D7 из коробки ни TDictionary<T> ни TList<string> нет. Хотя библиотек контейнеров данных для D7 было море, хоть на Торри посмотри, хоть на других развалах. Опять же, можешь в любой in-memory dataset загрузить, лишь бы в нем юникод был, но это я ужу не знаю какие. TClientDataSet из коробки и на юникоде основан вроде. RxLib/JediVCL TMemoryDS поглюкивает, но тоже сойдет, если загрузить и читать. У DevExpress есть, да много у кого. Хотя для 10К записей IMHO лучше всего найти хэш-массив(TDictionary) для D7 или возможно выдрать его из inifiles.pas ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 19:15 |
|
||
|
unicode и локальная база (dbf ?)
|
|||
|---|---|---|---|
|
#18+
Йо!Приходится долго ждать, а делать надо раза три в час. Делай дельту, изменения от предыдущей выгрузки. Йо!Вставляю сначала структуру - псевдо матрица столбцы и кол-во строк, затем построчно один столбец, другой и т.д. А записываешь как, через WriteLn ? тогда конечно все тормозит.... И ещё раз тебе советую внимательно посмотреть на Synopse mORMot пока они не забили болт на D7 Очень быстрый парсер JSON, поддержка SQLite и не-SQL баз данных, всё основано на юникоде (UTF-7), кажется поддержка zip Там очень много, это фреймворк полностью отличный в подходе от TDataSet - но тебе и не надо сразу ВСЁ у них брать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 19:19 |
|
||
|
|

start [/forum/topic.php?fid=58&msg=39607928&tid=2041190]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
191ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
79ms |
get tp. blocked users: |
1ms |
| others: | 291ms |
| total: | 607ms |

| 0 / 0 |
