LO-7.2

[mikekaganski]

А прямого пути, типа - Parent/Parent/Parent/... нет.

А можно совсем небольшой тестовый пример? Документ с кнопочкой и форма, в которую он встроен? Попробуем поискать окольный путь...

https://ask.libreoffice.org/t/get-the-cell-s-containing-s-having-anchored-the-button-that-fired-a-macro/15063/4
https://ask.libreoffice.org/t/libreoffice-api-given-a-formcontrol-how-to-find-the-hosting-shape/66378

[sokol92]

Здравствуйте, Михаил! Примерно так, но более технично.
Я с этим AccessibleContext провозился почти сутки, так что ориентируюсь почти с закрытыми глазами.
Ждем примера.

[Kadet]

Значит, продолжаю мучать свою БД.
Выяснился такой интересный казус.
Отвязал от формы все запросы, и привязанный к форме и ко всем полям-спискам.
База, в первые разы, очень даже живенько всё загружалось и входило в рабочий режим.
Повесил на кнопку привязку в нужных местах запросов. Чтобы привязывать их макросом и после загрузки формы.
На одном поле случился крах, а все остальные запросы привязались без проблем.

После краха снова загрузка стала очень долгой. (Впечатление, что какой-то накопительный эффект, о котором mikekaganski в своём баге описывал). Но всё же загружалась.
Жёстко подвязал к форме и полям все запросы, кроме проблемного.
Загрузилась.

Т.е. - вся соль в некоторых запросах.
Неподъёмным оказался такой запрос:

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

SELECT "Заказчик", "ID"  FROM "ЗАКАЗЧИКИ" GROUP BY "Заказчик", "ID"  ORDER BY UPPER("Заказчик") ASC
Думал опять проблема с дополнительными операторами, в данном случае с UPPER. Он нужен, потому что в FB есть проблемы с правильной сортировкой, по крайней мере, русских текстов - сначала всё сортируется по заглавным буквам, а затем идёт строчные. Оператор UPPER всё приводит к заглавным и после этого сортируется правильно, по-русски.

Так вот. Оказалось нет. Убрал UPPER, но проблема не решилась. Долгая долгая загрузка.
Думал проблема в самой таблице. Открывал все и все, в том числе и эта, открылись нормально, ошибок не выдали.
Возможно проблема в объёме - 1722 записи. Но в базе есть таблицы и по 9тыс. записей и они исполняются моментально.
Допустим этот:

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

SELECT "ID_No", "ID" FROM "ЗАКАЗЫ_ПОЗИЦИИ" GROUP BY "ID_No", "ID" ORDER BY UPPER("ID_No") ASC

Снова неясности.
А ведь этот проблемный запрос привязан у меня к каждой главной форме во всех базах. Он формирует список для фильтра по заказчику и очень важный (из опыта - наверное самый востребованный, вместе с номером заказа).

[Kadet]

Вот пример. Пустой. Макросов нет (не знаю, что вложить, чтобы не испортить чистоту эксперимента).
Только кнопку в calc нужно ставить макросом, потому как при каждой загрузке вложенный calc создаётся заново, как новый документ.
На кнопку не знаю что повесить.
Попробуйте хотя бы из Write добраться до Calc.
Если получится, расскажите как.
Если не получится, то повешу кнопку и в Calc. Будем пробовать найти обратный путь.

Я решаю эту проблему путём сложных манипуляций, поисковиков и листенеров (для подстраховки). Достаточно сложный процесс и не мало макросов.

[Kadet]

Неподъёмным оказался такой запрос:

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

SELECT "Заказчик", "ID"  FROM "ЗАКАЗЧИКИ" GROUP BY "Заказчик", "ID"  ORDER BY UPPER("Заказчик") ASC

Проверил этот же запрос в вынесенной БД. Мгновение и 2370 записей нагора.
Парадокс. Что-то неладное творится в этом Датском королевстве.

[Kadet]

С запросами разобрался.
Вот так прекрасно работает:

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

SELECT "Заказчик", "ID" FROM "ЗАКАЗЧИКИ" ORDER BY UPPER ( "Заказчик" ) ASC
Это получается, что в новой версии LO есть какие-то проблемки с группировками в запросах. Возможно, я не очень корректно их использовал (в частности DISTINCT были не очень корректны), а теперь и GROUP BY... Хотя на 100% уверен, что здесь он был использован совершенно корректно (хотя и бесполезно).
Хотя в других запросах подобная структура с GROUP BY работает безупречно.

Выяснил, что таблица не при чём. В некоторых подобных запросах, но с другими таблицами происходит тот же зависон.

[sokol92]

Вот пример

Большое спасибо, беру в работу. Все получится, только не сразу, так как, увы, есть еще не столь увлекательные занятия.
Первое удивление: всю жизнь считал, что OLE - проприетарный интерфейс Microsoft и работает только в MS Windows.

[Kadet]

Первое удивление: всю жизнь считал, что OLE - проприетарный интерфейс Microsoft и работает только в MS Windows.

Оно будет не последним. Уверяю.

[Kadet]

Задача для суперспецов.
Два запроса, в чём подвох?

Этот исполняется за секунду:

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

SELECT "РАЗМЕРЫ"."Разм", MIN("РАЗМЕРЫ"."ID"), "РАЗМЕРЫ"."R1", "РАЗМЕРЫ"."R2"
FROM "РАЗМЕРЫ", "ТОВАР"
WHERE "ТОВАР"."ID_razmer" = "РАЗМЕРЫ"."ID" AND "РАЗМЕРЫ"."Кр" > 2 AND "ТОВАР"."Остаток" > 0
GROUP BY "РАЗМЕРЫ"."Разм", "РАЗМЕРЫ"."R1", "РАЗМЕРЫ"."R2", "РАЗМЕРЫ"."Кр"
ORDER BY "РАЗМЕРЫ"."Кр" ASC, "РАЗМЕРЫ"."R1" ASC, "РАЗМЕРЫ"."R2" ASC

Этот виснет:

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

SELECT "Размер", "ID", "R1", "R2", "R3"
FROM "РАЗМЕРЫ"
WHERE "Кр">2 AND "Кр"<19
GROUP BY "Размер", "ID", "R1", "R2", "R3", "Кр"
RDER BY "Кр" ASC, "R1" ASC, "R2" ASC, "R3" ASC

В чём принципиальная разница для LO? Первый даже сложнее второго, потому что работает с двумя таблицами, но... неподъёмным оказывается второй. Уменьшение количество элементов (в частности Кр или R3 убирал) не помогает.
Пробовал подставлять наименование таблицы перед полями, как в первом ("РАЗМЕРЫ"."Размер"), не помогает.

[mikekaganski]

Первое удивление: всю жизнь считал, что OLE - проприетарный интерфейс Microsoft и работает только в MS Windows.

Так и есть. OLE в ЛО - это эвфемизм

[sokol92]

 

это эвфемизм

[Kadet]

Область поисков сужается.
Простейшие запросы:

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

SELECT "Размер" FROM "РАЗМЕРЫ"

И он же с группировкой:

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

SELECT "Размер" FROM "РАЗМЕРЫ" GROUP BY "РАЗМЕРЫ"."Размер"

Дают следующие результаты. (вложения).

В этом поле присутствуют русские символы, в частности "х", буквы или несколько слов.
Возможно таки кириллица? Хотя эти же поля, даже с группировкой, но с несколькими таблицами дают прекрасные результаты без искажений.

[Kadet]

Так и есть. OLE в ЛО - это эвфемизм

Главное, что работает.

[sokol92]

В большинстве диалектов SQL крайне не рекомендуется (или запрещено) применять не латинские буквы для именования объектов баз данных: таблиц, представлений (View), полей, индексов, триггеров и т.д. Лучше неукоснительно следовать этому.
Заголовки полей на русском языке всегда можно получить в результате выполнения SQL-запросов. Если база данных позволяет, то можно однократно записать View с таким "именующим поля" SQL-запросом.

[mikekaganski]

Область поисков сужается.

Найс! Воспроизводится на Вашей Cyanopica4. Можно попробовать найти проблему.