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

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

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

Войти
Новости: Часто задаваемые вопросы по LibreOffice и Apache OpenOffice.org
 
   Начало   Помощь Поиск Войти Регистрация    задать вопрос  
Страниц: 1   Вниз
  Печать  
Автор Тема: Ошибки LibreOffice 6.1  (Прочитано 3085 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Kadet
Форумчанин
***
Offline Offline

Сообщений: 91


« Стартовое сообщение: 19 Октябрь 2018, 17:39 »

С большим трудом перенёс свою БД на новую платформу LibreOffice 6.1.

Столкнулся с массой проблем.
1. Кириллицу в названиях таблиц и полей не воспринимает. Всё время выбрасывает сообщение о превышении лимита в 30 символов.
   - Решил проблему путём переименования всего и вся в латиницу, а чтобы не переделывать все макросы, трансформировав базу в Firebird переименовал всё обратно.

2. Проблема преобразования типа в числовые при выполнении завросов в макросах. В общем RowSet воспроизводится как String и не хочет переводиться ни в Double ни в Integer ни в другие числовые типы с помощью CDbl или CInt и т.п. При этом с CDate и CBool таких проблем нет.
 -Решил проблемы путём объявления числовых переменных типа Double и Integer и присвоению им выборки из RowSet.getString(x) только так удалось преобразовать переменные из запроса к нужному типу.
Из-за этого косяка так же не работают вычисления в запросах. Допустим 4,55*1447 в запросе выдаёт - 658 385, что в принципе верно, если поставить правильно запятую - 6 583,85. Т.е. - получается запятые в запросах просто игнорируются в всё берётся как целые числа.

3. При формировании отчётов - не хочет менять Тексты меток. Все метки выводятся с текстом Label, как их не меняй.
 - Этот баг пока остался нерешённым.
« Последнее редактирование: 19 Октябрь 2018, 17:43 от Kadet » Записан
mikekaganski
Мастер
*****
Offline Offline

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


« Ответ #1: 19 Октябрь 2018, 17:42 »

3. При формировании отчётов - не хочет менять Тексты меток. Всюду всё меняет на Label.
 - Этот баг пока остался не решённым.

tdf#119067
Записан

С уважением,
Михаил Каганский
Kadet
Форумчанин
***
Offline Offline

Сообщений: 91


« Ответ #2: 19 Октябрь 2018, 17:46 »

tdf#119067
Спасибо. Посмотрю.
Записан
mikekaganski
Мастер
*****
Offline Offline

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


« Ответ #3: 19 Октябрь 2018, 19:01 »

1. Кириллицу в названиях таблиц и полей не воспринимает. Всё время выбрасывает сообщение о превышении лимита в 30 символов.
   - Решил проблему путём переименования всего и вся в латиницу, а чтобы не переделывать все макросы, трансформировав базу в Firebird переименовал всё обратно.

tdf#119502

Насчёт №2 не нашёл баг - пожалуйста, создайте соответствующий багрепорт.
Записан

С уважением,
Михаил Каганский
Kadet
Форумчанин
***
Offline Offline

Сообщений: 91


« Ответ #4: 19 Октябрь 2018, 19:05 »

И вообще заметил некую недружбу этой жарптицы с числовыми форматами. Все INT со значениями "1" при трансформации превратились в "-254", так же много было косяков с всеми другими числами, типа "650,56" в какую-то невообразимую цифру преобразовал, все Dbl - превратил в "0.00". Причём системы в этих багах я не понял.
В общем пришлось всё сверять с прежними данными и редактировать всё вручную.
Записан
mikekaganski
Мастер
*****
Offline Offline

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


« Ответ #5: 19 Октябрь 2018, 19:07 »

Дело не в жарптице, а в мастере преобразования. Этот мастер активно допиливается, именно поэтому пока ещё оно не предлагается по умолчанию.
Записан

С уважением,
Михаил Каганский
Kadet
Форумчанин
***
Offline Offline

Сообщений: 91


« Ответ #6: 19 Октябрь 2018, 19:17 »

Насчёт №2 не нашёл баг - пожалуйста, создайте соответствующий багрепорт.
Багрепорт только в понедельник ибо всё на работе, а уже выходные.
Лучше опишу.

Макросом выполняю запрос с выборкой числовых данных (все типа "NUMERIK")
select X, Y, X*Y as Z from TABLE
RowSet.getString(3) неправильный результат произведения

Z = RowSet.getString(1)*RowSet.getString(2) - неправильный результат произведения.

Z = CDbl(RowSet.getString(1))*CDbl(RowSet.getString(2)) - "Ошибка преобразования типа"

X = CDbl(RowSet.getString(1)) - "Ошибка преобразования типа"

Всё решилось только так:
Dim X As Double
Dim Y As Double
Dim Z As Double
X = RowSet.getString(1)
(получается правильное значение уже преобразованное в Double)
Y = RowSet.getString(2)
Z=X*Y


Такая же проблема возникла и в запросе, когда в поле запроса прописываешь - "Вес"*"Цена" (поля таблицы) - сумма выдаётся неправильная.
« Последнее редактирование: 19 Октябрь 2018, 19:54 от Kadet » Записан
Kadet
Форумчанин
***
Offline Offline

Сообщений: 91


« Ответ #7: 19 Октябрь 2018, 19:19 »

Дело не в жарптице, а в мастере преобразования.
Наверное, но после трансформации рекомендовал бы тщательно проверять данные.
Записан
Kadet
Форумчанин
***
Offline Offline

Сообщений: 91


« Ответ #8: 5 Февраль 2019, 09:37 »

Ядро бд FireBird в LibreOffice 6.1 - просто дебилизм какой-то.
Не воспринимает запятые в вещественных числах, в которых эти числа и хранятся в его же таблицах (разделитель "," по умолчанию в русской локали).
Просто игнорирует их и в итоге даже при простейших запросах выдаёт просто бред какой-то.

Пример:
Поля А и B в таблице table
А = 6,600
В = 0,000
Делаю
SELECT (A-B) as С FROM table
Выдаёт
С = 6600
Записан
mikekaganski
Мастер
*****
Offline Offline

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


« Ответ #9: 5 Февраль 2019, 10:32 »

Ни в каких вменяемых СУБД никогда числа не хранятся с каким-то определённым разделителем "в локали ХХХ". Внутренний формат хранения чисел не зависит от разделителей дробной части.

Отсюда (и из текста возмущённого ответа) понятно, что ничего непонятно. Для понимания проблемы нужно не только рассказать, что "я смотрю на свой экран в свою БД, хочу увидеть ХХХ, а вижу УУУ", но и что это за своя БД: "поле А определено так (здесь SQL определения схемы, или, может, скриншот из мастера таблиц), поле B - так; данные в таблице такие (здесь, опять же, скриншот самой таблицы не помешал бы)"... А то ведь возможно, что где-то просто недоразумение, и в таблице на самом деле запятая - это разделитель тысяч.
Записан

С уважением,
Михаил Каганский
Kadet
Форумчанин
***
Offline Offline

Сообщений: 91


« Ответ #10: 5 Февраль 2019, 11:47 »

Скрины без проблем.
Scrin1 - установочные данные для полей таблицы.
Scrin2 - результат работы простого запроса, где Св.ост = Остаток-Резерв. Внизу сам запрос.
В результате выдаётся абсолютная хрень.


* Scrin1.jpg (84.6 Кб, 1013x598 - просмотрено 18 раз.)

* Scrin2.jpg (155.48 Кб, 873x735 - просмотрено 18 раз.)
Записан
mikekaganski
Мастер
*****
Offline Offline

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


« Ответ #11: 5 Февраль 2019, 12:05 »

Возможно, что поскольку NUMERIC хранится внутренне как целое (введённое число умножить на 10 в степени число десятичных знаков), FB не знает, какой подформат отображения выдать для выражений с такими форматами? если вместо
Код:
SELECT (A-B) as С FROM table
попробовать
Код:
SELECT CAST(A-B as NUMERIC(15,3)) as С FROM table
?
« Последнее редактирование: 5 Февраль 2019, 12:06 от mikekaganski » Записан

С уважением,
Михаил Каганский
Kadet
Форумчанин
***
Offline Offline

Сообщений: 91


« Ответ #12: 5 Февраль 2019, 12:17 »

М-да.
Код:

SELECT CAST(A-B as NUMERIC(15,3)) as С FROM table
Спасибо! Так помогло. Однако заморочка.
А в каком же формате в FB лучше хранить вещественные числа?

Видимо в DOUBLE PRECISION. Однако база изначально писалась под HSQLDB где подобных проблем не было, а при переносе данных тоже проблемы. Изменённые поля предлагает удалить и создать заново с обнулением всех данных.

В общем - что-то у них там недоработано.
« Последнее редактирование: 5 Февраль 2019, 12:22 от Kadet » Записан
mikekaganski
Мастер
*****
Offline Offline

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


« Ответ #13: 5 Февраль 2019, 12:22 »

Что значит "лучше"?

Разные СУБД как раз в частности отличаются разными "заморочками", которые в них есть (в отличие от других СУБД) для оптимизации (потому что по мнению разработчиков СУБД, именно это поможет лучше всего для производительности/точности/объёма/всегосразу)... поэтому для каждой СУБД надо внимательно смотреть особенности и выбирать под задачи.
Записан

С уважением,
Михаил Каганский
Kadet
Форумчанин
***
Offline Offline

Сообщений: 91


« Ответ #14: 5 Февраль 2019, 12:38 »

Та то понятно.
Однако, в возможностях FB включена целая куча числовых форматов (numeric, decimal, integer, double и пр.) и double стараюсь реже выбирать именно из соображений затрачиваемого на него наибольшего из всех объёма резервирования и, соответственно, падения скорости обработки подобных типов. А прочие, получаются, практически идентичны, в частности decimal и integer - без доп обработки в запросах, типа CAST(A-B as DECIMAL(10,2)), практически идентичны по умолчанию.
Записан
Страниц: 1   Вверх
  Печать  
 
Перейти в:  

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