Работа с большими файлами экселя

[ComodoHacker]

> какой то из них отвалился по причине опостылевшей уже на тот момент OutOfMemory

Конечно же DOM.

[Anderwonder]

«О, сколько нам открытий чудных готовит..» фирма Microsoft!

[dtcDev]

Я по работе сталкивался с IDE Mono Develop, Zend, Flash Develop, Eclipse, и еще парочкой. При всей «открыто-чудности» мелкомягких, Visual Studio — это лучшая IDE, и за это им большое спасибо. Их можно за многое любить и ненавидеть, и вообще тема для очередного холивара, который начинать как то не хочется, но некоторые их решения достойны уважения, как ни крути.

[Anderwonder]

Ну зачем расточаться «большим спасибо», они же не шкуродеры. Достаточно 450$).
Всё-всё — no hollywar.

[ComodoHacker]

В данном случае Microsoft не при чем.

[Eternalko]

О сколько тайн прекрасных, Вам предстоит еще познать.
Фирма Майкрософт тут ни при чем.

Ну какой интеллектуал запихивает такие данные в эксель?

[ComodoHacker]

> работать с файлами на 600-800 тыс строк кода

Ошибки тут нет? VBA-код что ли?

[s0L]

Рошаль тут непричем, -x документы мсофиса это ZIP архивы

[dtcDev]

Сорри, конечно Вы правы. Поправлю

[noonesshadow]

Стандарт, если шо, тут…
msdn.microsoft.com/en-us/library/dd922181(v=office.12).aspx

[radislav]

Я тут вообще мимо проходил, но можно из листингов убрать пустые строки?

[Meroving]

Эхх, это ж Source Code Highlighter. Он когда-то работал хорошо, но после очередного обновления Хабра стала выдаваться такая фигня, а поправить некому.

[faiwer]

Тест.
<source lang="c#">

using System;
using System.Collections.Generic;
using System.Data;
using System.Data.OleDb;
using System.IO;
using System.Linq;

<code>
using System;
using System.Collections.Generic;
using System.Data;
using System.Data.OleDb;
using System.IO;
using System.Linq;
Просто для проверки. В предпросмотре всё Ok. Никаких лишних строк, не знаю как получится в итоге :)

[dtcDev]

Сам не в восторге, знать бы еще как…

[faiwer]

попробуйте <source lang="c#">. Или вы его и используете?

[DeeKey]

Где-то полгода назад искал решения для экспорта-импорта файлов Excel на сервере.
Наткнулся на EPPlus и просто пищал от радости: не требует установки Офиса, простой API, не попалось ни единого бага (ну, на наших задачах — несколько worksheet'ов, несложное форматирование).

Проект пятилетний, много серверных модулей и клиентских приложений. К тому времени мы реально использовали в разных местах Interop, OLEDB, CSV и генерацию на основе XML-templates. У всех решений свои проблемы. Мы смотрели в сторону VSTO или Add-in Express'а, но EP+ очень удачно попался под руку.

Производительность EP+ заявляют сравнимую с тем что у вас получается — «Can now load 50 000 cells in seconds».

Да, конкретно у OLEDB — помимо естественных ограничений представления данных как реляционных и установки офисных DLL-ек (чего нам хотелось избежать на сервере), была еще заморочка с автоматическим распознованием типа данных по первым N (default 8) строкам. Если в первых строках в колонке шли цифры, то появление потом цифро-буквенного значения передавалось как DBNull и надо бвло лезть в реестр чтобы это исправить.

[zzeneg]

Я для работы с xlsx-файлами пользовался этим кодом. Правда с такими большими файлами не работал, не знаю насчет производительности.

[gibson_dev]

Юзаю библитеку libxl — офиса не надо, написана на си, работает под все чем можно (iOS даж есть) — весьма шустрая ошибок не встречал.
Вообщем рекомендую к использованию.

[FractalizeR]

А как у нее насчет сотен тысяч строк?

[gibson_dev]

Если дадите пример — проверю, сколько времени уйдет на чтение

[dtcDev]

к сожалению, я сомневаюсь, что заказчику понравилась бы массовая рассылка боевых данных :)

[gibson_dev]

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

[Valery35]

А если в access перенести? Для него такие объемы не проблема.

[dtcDev]

А если File->SaveAs->CSV, то жизнь вообще прекрасна: StreamReader stmReader=File.OpenText(.....);
Такая бредовая идея во время мытарств кстати проскакивала :)))) Но негоже было заставлять залезать и пересохранять документы.

Проблема всех проектов (а на самом деле норма), что нам приходится работать с тем, что дают, и никуда от этого не денешься.

[Valery35]

Посмотрите возможности импорта в access. Там такие полезные вещи есть как вынос ошибок вставки в отдельную таблицу, настройки шаблона при импорте.
И кодировать не надо (для меня это плюс) :)

[dtcDev]

проблема была в том, что задача ставилась как:
«вот те файлы, нужно чтоб в программе указал файл, кнопку бздынь, оно ууууууух, потом тырлинь-окей. А мы чтобы своими делами занимались пока суть да дело»

т.е. процесс автоматизируем максимально. И о каких либо сторонних действиях со стороны оператора речи быть не могло

[meta4]

Не подумайте что лезу не в свое дело, просто действительно интересно откуда могут взяться такие большие Exel файлы и почему именно в этом формате, раз они явно не для чтения/редактирования человеком?

[Valery35]

По моей практике такое часто возникает при передаче данных в результате экспорта из какой нибудь БД.

[dtcDev]

Отчеты по продажам одной компании. Отчет за месяц весит примерно 250 метров (по одной стране)

[dtcDev]

Итаки да, дополню. Такие файлы — настолько удивительная редкость, что большинство попросту не столкнется с такими объемами. Но данная задача позволила нам узнать новое: не только то, что такие файлы существуют в природе, но и то, как написать более быстрый и менее ресурсоемкий загрузчик из экселя. Пока что на других своих проектах я не хочу возращаться к Interop

[Valery35]

Это обычный вопрос при переносе данных между системами.
Не бакап же отдавать :)

[Dyr]

Вот если честно, то за такое канделябром по морде, ИМХО, надо, поскольку ничего Excel-специфичного там не используется, а значит, вполне можно было бы обойтись обычным и кросс-платформенным CSV.

[HomoLuden]

Бывают логи в XML и по несколько гигов.

[ruikarikun]

Я обычно в таких случаях сохранял как CSV, а дальше — по старинке.

[dtcDev]

про CSV отписался выше — стояла задача «одну кнопочку, чтобы было красиво»

[f0b0s]

Когда мне нужно было такое, я просто распарсил SpreadsheetML. Стандарт — открытый. Опыт у меня уже был (так парсил и ворд и ООо документ). Писать — пара тыщ строк кода, пара дней.

[dtcDev]

Это был последний вариант, если бы выложенный не сработал

[to_climb]

Provider=Microsoft.ACE.OLEDB.12.0 — ещё хорошо бы упомянуть, откуда есть берётся этот провайдер БД (стандарный, с офисом ставится, отдельный).

[to_climb]

4Гб оперативки и OutOfMemory никак не связаны — заканчивается 2Гб виртуального адресного пространства процесса.
Функция NewProcent очень порадовала =)

А Interop — штука для неторопливых, но иногда это единственный вариант. Делал через неё раскраску файлов (regexp'ами) — за несколько часов 40k строк отчёта переварила.

[m_a_d]

Когда дело доходит до форматирования — большинство сторонних открытых решений действительно не подходят. Мы в нашем софте в итоге, устав от тормозов и глюков особенностей Interop, обзавелись вот этой штукой. В работе с ней тоже есть нюансы, но в целом всё сильно упростилось.

[orionll]

А пробовали Open XML SDK?

[alon]

В сторону NPOI не смотрели? Установки не требует, пара длл-ок и все. По скорости все устраивает (60к строк в xls пишет моментально), хотя настолько большие файлы как у автора обрабатывать не приходилось.

[Sharomank]

>>text +=
конкатенация строк в цикле зло!