Ошибки LibreOffice 6.1

[Kadet]

С большим трудом перенёс свою БД на новую платформу 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, как их не меняй.
- Этот баг пока остался нерешённым.

[mikekaganski]

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

tdf#119067

[Kadet]

tdf#119067

Спасибо. Посмотрю.

[mikekaganski]

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

tdf#119502

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

[Kadet]

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

[mikekaganski]

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

[Kadet]

Насчёт №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

Такая же проблема возникла и в запросе, когда в поле запроса прописываешь - "Вес"*"Цена" (поля таблицы) - сумма выдаётся неправильная.

[Kadet]

Дело не в жарптице, а в мастере преобразования.

Наверное, но после трансформации рекомендовал бы тщательно проверять данные.

[Kadet]

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

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

[mikekaganski]

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

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

[Kadet]

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

[mikekaganski]

Возможно, что поскольку NUMERIC хранится внутренне как целое (введённое число умножить на 10 в степени число десятичных знаков), FB не знает, какой подформат отображения выдать для выражений с такими форматами? если вместо

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

SELECT (A-B) as С FROM table попробовать

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

SELECT CAST(A-B as NUMERIC(15,3)) as С FROM table?

[Kadet]

М-да.

Код:

SELECT CAST(A-B as NUMERIC(15,3)) as С FROM table

Спасибо! Так помогло. Однако заморочка.
А в каком же формате в FB лучше хранить вещественные числа?

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

В общем - что-то у них там недоработано.

[mikekaganski]

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

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

[Kadet]

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