База на основании XLS-файла

[adi_den2013]

По второму вопросу, думаю этим - ignore_first=false я всё предусмотрела.

Насчёт пустой второй строки... Проверю сейчас.

[adi_den2013]

Гмм.. Кстати, пустая строка образовывается после выполнения SQL-команды SET TABLE "PERSON2" SOURCE "person3.txt;ignore_first=false;fs=\t;encoding=ANSI"   

[mikekaganski]

Ещё: нет ли проблемы в имени encoding? См. https://docs.oracle.com/javase/8/docs/technotes/guides/intl/encoding.doc.html (я уж не говорю о ерунде о том, что "OEM=WIN=1251. DOS=ANSI=866").

[adi_den2013]

Ещё: нет ли проблемы в имени encoding? См. https://docs.oracle.com/javase/8/docs/technotes/guides/intl/encoding.doc.html (я уж не говорю о ерунде о том, что "OEM=WIN=1251. DOS=ANSI=866").

Разве я не капитан-очевидность  ? (см. кодировку текстового файла)

[mikekaganski]

Об этом и речь. У Вас в ответе #13 скриншот Image008.jpg показывает OEM, хотя я бы предположил, что там должно быть windows-1251 или Cp1251

[adi_den2013]

"OEM=WIN=1251

Разве это не одно и то же?

[adi_den2013]

Впрочем хрен редьки не слаще...

[mikekaganski]

Это ерунда, написанная для того, чтобы запутать Вас. Во-первых, OEM никогда не была равна WIN или 1251. Это ANSI в русских Windows определяется как кодировка 1251. А OEM всегдя была DOS, т.е. 866,

А во-вторых, я не уверен, что hsqldb (или java) понимает эти Windows-specific (да ещё и locale-specific) сокращения.

[adi_den2013]

Не проходит связь. Если бы дело было в кодировке, то в таблицу PERSON2 попадала бы абракадабра, но попадала бы. Я так считаю.

[adi_den2013]

Замораживаю ветку.

Отказываюсь в пользу БД SQLite. Уже перенесла данные из таблицы dbf через CSV в таблицу SQLite, подключилась к OpenOffice Base.

Спасибо всем, кто помогал  .

[economist]

adi_den2013 - вы поступили правильно! HSQLDB не годится для реальной работы. SQLite просто божественно надежней и быстрее. Кстати, по сети *.sqlite файл можно расшарить и пользоваться комфортно одновременно 3-5 пользователям через ODBC (из нескольких Base).
Еще подскажу редактор для работы с SQLite извне - addon к Firefox - SQLite Manager. https://addons.mozilla.org/ru/firefox/addon/sqlite-manager/?src=search Оно полностью меняет подход к работе с Sqlite. Ахтунг - в нем используется движок SQLite из FireFox, а не тот, что в системе. В нем включены некоторые модули (FTS, ICU итп).   


Проблему отсутствия связи с TXT-файлом в HSQLDB - могу объяснить только невыполнением условия создания таблицы. Повторюсь: 
Сама таблица д.б. типа TEXT, то есть создана SQL-конструкцией, а не в режиме дизайна:

CREATE TEXT TABLE <tablename> (<column definition> [<constraint definition>])

Насчет кодировок - я ошибся, поправил и дополнил пост #12: WIN=1251. DOS=OEM=866. UTF-8=65001   

[adi_den2013]

Еще подскажу редактор для работы с SQLite извне - addon к Firefox - SQLite Manager. https://addons.mozilla.org/ru/firefox/addon/sqlite-manager/?src=search Оно полностью меняет подход к работе с Sqlite. Ахтунг - в нем используется движок SQLite из FireFox, а не тот, что в системе. В нем включены некоторые модули (FTS, ICU итп).

Спасибо за дополнение. Я уже протестировала несколько менеджеров БД SQLite и остановилась на 2-х (привожу скрины)

FireFox не пользуюсь. Поэтому расширение не актуально.

[economist]

adi_den2013 - из этих двух приложений первое не подсвечивает значения по типам (для написания SQL-запросов это очень важно оказалось), а второе просто не будет работать с кириллическими таблицами/полями и м.б. проблемы с кириллицей в алиасах. Плюс Studio не поддерживает сортировку результата по щелчку, а это означает что любой запрос с группировками - и я, и вы - напишете в этом приложении за втрое большее число итераций, чем в SQLite Manager или другом.

Я за кириллицу и в именах таблиц, и в полях, и в именах представлений. Как только я "русифицировал" корпоративную БД - число писателей запросов выросло с 3-х до 8-ми человек, а число новых запросов в месяц - удвоилось. Есть такая важная тема - популяризация. Если нет желания все делать самому - сделай так, чтобы другие могли сделать это по твоему указанию. А еще лучше если они сами захотят этого.

Никто меня не убедит что в базе данных должна быть таблицы с "устоявшимися" именами вида Employers, Enterprises, Counteragents, Warehouses и тд, потому что я попробовал таблицы и поля на русском и офигел от того насколько это удобнее и мне, англоговорящему, и другим. Смотрите насколько понятен запрос "на русском" в моей методичке по объединениям:

Код Выделить Развернуть


-- Здесь приводятся все виды JOIN-ов. Задача: В Табл КОНТР есть телефон, а в Табл ОСВ - кред. задолженность (СКК), нужно увидеть должников,
-- долг и телефон в одной таблице. Выведем Контрагента из 2-х таблиц, где есть одинаковое поле - ИНН. Но т.к. ИНН есть не у всех (у иностранцев нет,
-- у физлиц нет) и есть филиалы+ГК с одинаковым ИНН, то соединять будем по склейке "ИНН+Имя". Считаем что "однофамильцев" без ИНН и
-- иностранных юрлиц - нет, но в жизни бывает всякое)

-- 1) Cначала "старый" стиль объединения, с WHERE (без JOIN)
SELECT КОНТР.Наименование, ОСВ.Контрагент, Телефон, КОНТР.ИНН, Счет, СКК
FROM ОСВ, КОНТР
WHERE (СКД+СКК)<>0
AND КОНТР.ИНН||КОНТР.Наименование=ОСВ.ИНН||ОСВ.Контрагент

-- 2) Это - "натуральное" объединение, итог и скорость те же, не надо называть поля, по которым объединять, но если выводим само
-- поле - надо писать ИмяТаблицы.Поле
SELECT КОНТР.Наименование, ОСВ.Контрагент, Телефон, КОНТР.ИНН, Счет, СКК
FROM ОСВ -- здесь упоминается только одна таблица
NATURAL JOIN КОНТР -- после слова JOIN упоминается вторая, прилепляемая таблица. ОСТОРОЖНО! Если
-- совпадений имен полей нет - будет Cross-соединение, перемножение строк, может все подзависнуть!

-- 3) Это "Простой" или INNER JOIN, итог и скорость те же, считается более понятным
SELECT КОНТР.Наименование, ОСВ.Контрагент, Телефон, КОНТР.ИНН, Счет, СКК
FROM ОСВ -- здесь упоминается только одна таблица
JOIN КОНТР
ON КОНТР.ИНН||КОНТР.Наименование=ОСВ.ИНН||ОСВ.Контрагент
-- указываем какие поля должны совпадать, они могут отличаться названием, можно использовать выражения, формулы итп.
-- Также можно дописать слово INNER для красоты, итог и скорость те же: INNER JOIN КОНТР ON...

-- 4) А вот совсем другое объединение: ко ВСЕМ строкам таблицы OSV прилепятся значения из KONTR, то есть это можно
-- назвать "присоединением" (так работает ф-я =ВПР() в Excel)
SELECT КОНТР.Наименование, ОСВ.Контрагент, Телефон, КОНТР.ИНН, Счет, СКК
FROM ОСВ -- здесь и далее упоминается только одна таблица!
LEFT OUTER JOIN КОНТР
ON КОНТР.ИНН||КОНТР.Наименование=ОСВ.ИНН||ОСВ.Контрагент


[economist]

Ниже приведу фрагмент своей рецензии "на тему" всех SQL-редакторов:

Помимо названных BASE и SQLite Manager - есть по меньшей мере 50 сторонних редакторов для SQLite, и было бы нечестно забыть о них. Они все были проверены, и относительно близким по удобству признаны еще несколько программ, поддерживающих подсветку SQL-фраз и типов значений, сортировку по щелчку (как в SQLite Manager). Это замечательный и миниатюрный SQLiteSpy (правда, лицензия для коммерческого использования обязывает сделать им добровольное пожертвование (donate) в любом размере (на вашей совести).
Также вполне приятным оказался редактор SqliteExpert Personal Edition - SQLiteExpertPers (хоть и без подсветки типов значений, но с удобным календарем для выбора дат), бесплатный для бизнеса.
Определенный интерес представляет редактор DB Browser for SQLite -  SQLiteDatabaseBrowserPortable, который имеет уникальную возможность строить и экспортировать XY-графики по данным таблиц и запросов, а также прочие "фишки", но в целом он кажется чуть более медленным.
Стоит упомянуть бесплатный редактор ViewODBC http://alekseyrybakov.narod.ru/ViewODBC.html, он хоть и на английском, но с хорошей русской справкой и подробной информацией о свойствах подключения. Все остальные, не упомянутые редакторы - плохие (нет поддержки сортировки по щелчку, корежатся кириллические поля/таблицы), и, пожалуй, не надо на них тратить время, по крайне мере до конца 2017 г.      

[rami]

...а второе просто не будет работать с кириллическими таблицами/полями и м.б. проблемы с кириллицей в алиасах. Плюс Studio не поддерживает сортировку результата по щелчку, а это означает что любой запрос с группировками - и я, и вы - напишете в этом приложении за втрое большее число итераций, чем в SQLite Manager или другом.

Что-то не заметил проблем с кириллицей и сортировкой щелчком по заголовку столбца в SQLiteStudio.