Форум поддержки пользователей. LibreOffice, Apache OpenOffice, OpenOffice.org

Форум поддержки пользователей. LibreOffice, Apache OpenOffice, OpenOffice.org

25 Сентябрь 2017, 12:58 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
Новости: Вы можете задать вопрос по LibreOffice или Apache OpenOffice  без регистрации, используя форму
 
   Начало   Помощь Поиск Войти Регистрация    задать вопрос  
Страниц: « 1 2 3 »   Вниз
  Печать  
Автор Тема: База на основании XLS-файла  (Прочитано 1182 раз)
0 Пользователей и 1 Гость смотрят эту тему.
adi_den2013
Постоялец
***
Online Online

Пол: Женский
Расположение: Донецкая обл.
Сообщений: 237


« Ответ #15: 11 Сентябрь 2017, 10:00 »

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

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

Яна (in real)
adi_den2013
Постоялец
***
Online Online

Пол: Женский
Расположение: Донецкая обл.
Сообщений: 237


« Ответ #16: 11 Сентябрь 2017, 10:12 »

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

Яна (in real)
mikekaganski
Ветеран
*****
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 581


« Ответ #17: 11 Сентябрь 2017, 10:19 »

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

С уважением,
Михаил Каганский
adi_den2013
Постоялец
***
Online Online

Пол: Женский
Расположение: Донецкая обл.
Сообщений: 237


« Ответ #18: 11 Сентябрь 2017, 10:29 »

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

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


* Image006.jpg (192.3 Кб, 1393x425 - просмотрено 6 раз.)
Записан

Яна (in real)
mikekaganski
Ветеран
*****
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 581


« Ответ #19: 11 Сентябрь 2017, 10:32 »

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

С уважением,
Михаил Каганский
adi_den2013
Постоялец
***
Online Online

Пол: Женский
Расположение: Донецкая обл.
Сообщений: 237


« Ответ #20: 11 Сентябрь 2017, 10:35 »

"OEM=WIN=1251

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

Яна (in real)
adi_den2013
Постоялец
***
Online Online

Пол: Женский
Расположение: Донецкая обл.
Сообщений: 237


« Ответ #21: 11 Сентябрь 2017, 10:38 »

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


* Image010.jpg (188.54 Кб, 1392x433 - просмотрено 9 раз.)

* Image009.jpg (94.76 Кб, 422x433 - просмотрено 7 раз.)
Записан

Яна (in real)
mikekaganski
Ветеран
*****
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 581


« Ответ #22: 11 Сентябрь 2017, 10:38 »

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

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

С уважением,
Михаил Каганский
adi_den2013
Постоялец
***
Online Online

Пол: Женский
Расположение: Донецкая обл.
Сообщений: 237


« Ответ #23: 11 Сентябрь 2017, 11:17 »

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

Яна (in real)
adi_den2013
Постоялец
***
Online Online

Пол: Женский
Расположение: Донецкая обл.
Сообщений: 237


« Ответ #24: 12 Сентябрь 2017, 10:56 »

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

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

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


* Image001.jpg (165.91 Кб, 649x683 - просмотрено 10 раз.)
Записан

Яна (in real)
economist
Ветеран
*****
Offline Offline

Сообщений: 687


« Ответ #25: 17 Сентябрь 2017, 11:09 »

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
Постоялец
***
Online Online

Пол: Женский
Расположение: Донецкая обл.
Сообщений: 237


« Ответ #26: 18 Сентябрь 2017, 09:05 »

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

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

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


* Image003.jpg (669.31 Кб, 1075x865 - просмотрено 12 раз.)

* Image004.jpg (350.56 Кб, 823x959 - просмотрено 9 раз.)
Записан

Яна (in real)
economist
Ветеран
*****
Offline Offline

Сообщений: 687


« Ответ #27: 18 Сентябрь 2017, 12:14 »

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 КОНТР.ИНН||КОНТР.Наименование=ОСВ.ИНН||ОСВ.Контрагент
« Последнее редактирование: 18 Сентябрь 2017, 12:41 от economist » Записан

Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...
economist
Ветеран
*****
Offline Offline

Сообщений: 687


« Ответ #28: 18 Сентябрь 2017, 12:38 »

Ниже приведу фрагмент своей рецензии "на тему" всех 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 г.      
« Последнее редактирование: 18 Сентябрь 2017, 12:41 от economist » Записан

Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...
rami
Гуру
*******
Offline Offline

Пол: Мужской
Сообщений: 2 185


MacBook Pro, LibreOffice и Apache OpenOffice


« Ответ #29: 18 Сентябрь 2017, 12:51 »

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


* SQLiteStudio.png (99.97 Кб, 721x346 - просмотрено 3 раз.)
Записан

Страниц: « 1 2 3 »   Вверх
  Печать  
 
Перейти в:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!