Calc: Как избавиться от подгонки строк при загрузке документа?

[sokol92]

@hanya - это голова... (c)  

Я прочитал все (!) сообщения @hanya на форуме, даже специально ради этого зарегистрировался.
В указанном фрагменте все действия понятны, по-видимому, это позволяет обойти часть стандартных действий Calc при открытии документа. По этой же ссылке я узнал о существовании асинхронного вызова методов.

[eeigor]

Да, понятно. В смысле: читай себе и всё. Но между "понятно" и написать самому - приличная дистанция. Но для меня "понятно" - это очень даже неплохо.
Впрочем, чтение чужого кода - это одни из путей эффективного обучения.

[sokol92]

Заглянул на Ask - тишина (воз и ныне там). На нашем форуме быстрее можно "договориться".

Это зависит от того, закладка какого форума активна у Михаила. 

[eeigor]

Да я это уже давно понял. LOL
Но Вас, Владимир, я тоже регулярно просматриваю... Причём иногда и на форуме planetaexcel.ru

[eeigor]

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

Edit:
Один из путей - это разделение файла на 2: интенсивный ввод данных; анализ данных.
Однако я пока что не работал с линкованными файлами в Calc, и не знаю, какие подводные камни меня ждут. Кто пробовал? В двух словах...

[sokol92]

Можно после присвоения значений ячейкам и пересчета высоты строк менять свойство этих строк OptimalHeight на False (в цикле по одной). См. здесь. Тогда при открытии файла высота строк пересчитываться не будет.

В Excel внешние ссылки приносят гораздо больше проблем, чем удобств.

[economist]

Линкованные файлы забраковал после того как научился разбираться с Формами.

Данные храню в однофайловой SQLite (ч/з JDBC/ODBC), это 100-1500 тыс. строк х 100 полей, работает все быстро, почти мгновенно. На единственном листе книги Calc, c 10-й строки, данные SQLite выводятся SELECT-запросом, BASIC-методом doImport. Этот метод выводит неформатированный текст, и подбора высоты строк нет. Это самый быстрый метод из BASIC.

C 1-й по 9-ю строки - реализован "UX-интерфейс" в виде списков Проверки данных, формул итп. Их значения подставляются в SELECT запросы. Или это контролы, связанные с БД.

Сам файл ODS - по сути оказывается "пустышкой", он даже не сохраняется. Я его используют в режиме Сервис - Совместно... для 2-3 активных юзверей - работает четко, как MS Access и временами даже быстрее. А закрываю кнопкой с ThisComponent.Dispose(), без лишних вопросов.

Цимес doImport - в легкой подмене SQL-запроса, в результате нет необходимости тащить на лист огромные объемы данных. Можно выводить их часть (сотни строк), например, неоплаченные счета, кредиторы, сотрудники итд. Или сгруппированные агрегаты. Или уники.

Козыри в рукаве, которые нужны не всегда - это python c быстрой либой sqlite3, которая быстрее даже родной консольной C-утилиты sqlite3.exe. Питон способен уложить в БД гигабайтный текстовый CSV-файл примерно за 4 секунды. Плюс pandas в разы облегчает ETL/EDA, и нет нужды лохматить 100-строчные SQL-запросы.

Кстати, они тоже пригождаются, особенно если быстро накодить UDF для SQL и загрузить их в API SQLite. UDF на питоне пишутся легко, т.к. срезы и работа со строками, списки, множества, словари - все это очень логично и просто.  

Одним словом в этой схеме Calc является "мордой" к БД, и его привычные табличные фишки помогают в освоении ПО. А всю бизнес-логику тянут СУБД, SQL и pandas. Если строк становится больше 3 млн. - становится некомфортно, особенно при одновременном сетевом доступе к файлу 3-5 юзеров (читают 4 или пишет 1). Наверно для таких объемов надо клиент-серверную СУБД mysql/postgresql, штатные коннекторы все хвалят и они точно работают шустро. Перейти на них с SQLite, думаю, можно за неделю. И большая часть времени уйдет не на переписывание SQL-запросов, а на админство и настроку сервера с БД.  
 

[sokol92]

большая часть времени уйдет не на переписывание SQL-запросов

Postgre - довольно капризная особа и такого пренебрежения к себе может и не простить. У нас есть опыт перевода систем с Oracle на Postgre. 

[sokol92]

Игорь, это не не Ваш случай: tdf#147398 (детально не смотрел)?

[eeigor]

Да, вроде, нет. Я пока на 7.2... Проблема только выскочила с обновлением формул массива. Но должен сказать, что в свете последних функций (тех, что дополнили SUMPPDUCT: IFS, SUMIFS, COUNTIFS...) массивных формул стало меньше. Но я считаю дубликаты (в одной таблице) и двойников (в разных таблицах), и без формул массива никак.

Например (выводит список дубликатов в формате: №1. Фамилия1; №2. Фамилия2;...):
{=TEXTJOIN("; ";1;IF(COUNTIF(ФИО;ФИО)>1;Nпп&". "&ФИО;""))}
где Nпп, ФИО - именованные диапазоны.

COUNTIFS умеет обрабатывать массивы, а IF нет (из-за неё и вставляются фигурные скобки). ТEXTJOIN прекрасная функция, однако. И здесь она пропустит записи, не отвечающие условию (пустые строки, полученные от IF).

[eeigor]

Но решение от @Hanya позволяет-таки загружать файл из меню LO Calc с отключенной подгонкой строк...

Заметил, что при такой загрузке события листа (у меня таких листов несколько) все макросы будут молча отключены. Вся автоматизация расширенного фильтра не работает, и это неприемлемо. Хотя код от @hanya нацелен на другое:
doc.IsAdjustHeightEnabled = False

Edit: хотя мне кажется, что макросы просто не подключаются. И можно ли это сделать принудительно, не знаю...