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

Автор adi_den2013, 6 сентября 2017, 15:41

0 Пользователи и 1 гость просматривают эту тему.

adi_den2013

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

Насчёт пустой второй строки... Проверю сейчас.
Яна (in real)

adi_den2013

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

mikekaganski

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

adi_den2013

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

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

mikekaganski

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

adi_den2013

Яна (in real)

adi_den2013

Впрочем хрен редьки не слаще...
Яна (in real)

mikekaganski

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

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

adi_den2013

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

adi_den2013

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

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

Спасибо всем, кто помогал  :).
Яна (in real)

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

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

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

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

economist

#27
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

#28
Ниже приведу фрагмент своей рецензии "на тему" всех 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

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