Я бы подошел с другой стороны:

1) А может ли пользователь принять два файла? Каким образом он хочет эти два файла получить?

2) А нафига два файла, почему все не запихнуть в один?

Расшифровка выросла и стала сильно больше 65к строк(2М+)


Ну и третий:
и что? находятся люди, которые все эти 65 K строк глазами с экрана просматриваю? начальству денег на картриджи/тонер/бумагу, что бы 65 K строк печатать на принтере не жалко? 65K строк, это AFAIK как минимум 1000 страниц печатного текста, а то и больше. Около 5 килограмм при стандартной офисной бумаге. Таким отчетом вполне и убить можно, хорошее средство самообороны ))) получилось.


Когда такое кол-во данных участвует не в экспорте/импорте, интеграции, BI и т.д., а в отчете... Т.е. в вещи, которая в "классическом" случае, должна из принтера в виде бумажки вылезти... Возникают сомнение.... Что проблема кроется не в средстве/коде программы, а в самой постановке задачи.

IMHO & AFAIK

Be or not to be...Да в том дело, что сама форма отчета для регулятора и она не терпит вмешательств в форматирование Excel-документа. Поэтому rtf-шаблон для нее - не вариант

Тут помочь не могу. Т.к. работал с паблишером в то время, когда он еще "чистый" Excel шаблоны не понимал. (ну или нужно паблишер ставить и доки читать)

Excel в паблишере делали "ручками" через XMLT преобразования - соответственно никаких проблем побить данные по листам экселевской книги, лично у меня бы не было )))

Про Excel шаблоны нужно у Jack Carver'а спрашивать, если он еще в данной конференции обитает.

Leonid Kudryavtsev
Ну это классический вопрос... И на него есть столь же классический ответ - "классический" случай, как водится, часто отличается от реальной жизни :)
Пользователю сделали отчет. В нем большая часть областей деятельности предприятия, скажем так. Большинство сумм собраны с аналитических модулей(а не с синтетики(ГК)). Каждая сумма собрана из 100500 договоров, счетов-фактур и всего такого прочего. Данных, чтобы проверить эти сборные суммы он не имеет, а, значит, желает получить расшифровку. А вот объем этой расшифровки велик. Ясно, что печатать ее никто и никогда не будет, но смотреть ее будут

Это понятно.

I)
Просто если делать по "хорошему", то ответ на свои бизнес задачи человек должен __удобно__ в системе находить.

А то выглядит так, что сделали систему (или допилили существующую западную), в которой работать не возможно, поэтому все данные выгрузим в Excel, путь там разбираются.

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

Разумеется все это чисто теоретически и сферично-вакуумно. Но обычно такие задачи относили в разряд "интеграция/экспорт" или коллегам в модуль BI сплавляли.

По более чем 4 проектам, даже ни одного такого отчета вспомнить не могу. (кроме книги покупок/продаж в одной из систем, но явно ошибочно сделанной! по принципу "на отеб...сь")

Были отчеты сделанные специально для анализа данных - фактически ручная аналитика для OeBS на Oracle Reports + XML Publisher, но и они по параметрам были сделаны так, что результат отчета вполне можно было "распечатать". Просто поля для аналитики (группировок, сортировок) настраивались. Пара таких отчетов заменяла несколько десятков (30-40) старых отчетов в старой 1C системе (заменяли 1C на OeBS)

II)
Не знаю как сейчас, но раньше, XML Publisher работал через DOM. Т.ч. такие отчеты вполне могли всю память в 32 разрядной JVM скушать. Возможно сейчас что-то поменялось (вроде Xalan / Xerser уже давно XMLT делают через SAX)

P.S.
Вам сотрудники не требуются? А то я безработный

p.s. в каждой шутке есть доля не шутки. В принципе запросто. Если что, мой e-mail в профиле.