Pull to refresh

Comments 43

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

Конечно же DOM.
«О, сколько нам открытий чудных готовит..» фирма Microsoft!
Я по работе сталкивался с IDE Mono Develop, Zend, Flash Develop, Eclipse, и еще парочкой. При всей «открыто-чудности» мелкомягких, Visual Studio — это лучшая IDE, и за это им большое спасибо. Их можно за многое любить и ненавидеть, и вообще тема для очередного холивара, который начинать как то не хочется, но некоторые их решения достойны уважения, как ни крути.
Ну зачем расточаться «большим спасибо», они же не шкуродеры. Достаточно 450$).
Всё-всё — no hollywar.
О сколько тайн прекрасных, Вам предстоит еще познать.
Фирма Майкрософт тут ни при чем.

Ну какой интеллектуал запихивает такие данные в эксель?
> работать с файлами на 600-800 тыс строк кода

Ошибки тут нет? VBA-код что ли?
Рошаль тут непричем, -x документы мсофиса это ZIP архивы
Сорри, конечно Вы правы. Поправлю
Я тут вообще мимо проходил, но можно из листингов убрать пустые строки?
Эхх, это ж Source Code Highlighter. Он когда-то работал хорошо, но после очередного обновления Хабра стала выдаваться такая фигня, а поправить некому.
Тест.
<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. Никаких лишних строк, не знаю как получится в итоге :)
Сам не в восторге, знать бы еще как…
попробуйте <source lang="c#">. Или вы его и используете?
Где-то полгода назад искал решения для экспорта-импорта файлов 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 и надо бвло лезть в реестр чтобы это исправить.
Я для работы с xlsx-файлами пользовался этим кодом. Правда с такими большими файлами не работал, не знаю насчет производительности.
Юзаю библитеку libxl — офиса не надо, написана на си, работает под все чем можно (iOS даж есть) — весьма шустрая ошибок не встречал.
Вообщем рекомендую к использованию.
А как у нее насчет сотен тысяч строк?
Если дадите пример — проверю, сколько времени уйдет на чтение
к сожалению, я сомневаюсь, что заказчику понравилась бы массовая рассылка боевых данных :)
мне хватит только поля допустим с именем, остальные можете заменить на что угодно или убрать
А если в access перенести? Для него такие объемы не проблема.
А если File->SaveAs->CSV, то жизнь вообще прекрасна: StreamReader stmReader=File.OpenText(.....);
Такая бредовая идея во время мытарств кстати проскакивала :)))) Но негоже было заставлять залезать и пересохранять документы.

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

т.е. процесс автоматизируем максимально. И о каких либо сторонних действиях со стороны оператора речи быть не могло
Не подумайте что лезу не в свое дело, просто действительно интересно откуда могут взяться такие большие Exel файлы и почему именно в этом формате, раз они явно не для чтения/редактирования человеком?
По моей практике такое часто возникает при передаче данных в результате экспорта из какой нибудь БД.
Отчеты по продажам одной компании. Отчет за месяц весит примерно 250 метров (по одной стране)
Итаки да, дополню. Такие файлы — настолько удивительная редкость, что большинство попросту не столкнется с такими объемами. Но данная задача позволила нам узнать новое: не только то, что такие файлы существуют в природе, но и то, как написать более быстрый и менее ресурсоемкий загрузчик из экселя. Пока что на других своих проектах я не хочу возращаться к Interop
Это обычный вопрос при переносе данных между системами.
Не бакап же отдавать :)
Вот если честно, то за такое канделябром по морде, ИМХО, надо, поскольку ничего Excel-специфичного там не используется, а значит, вполне можно было бы обойтись обычным и кросс-платформенным CSV.
Бывают логи в XML и по несколько гигов.
Я обычно в таких случаях сохранял как CSV, а дальше — по старинке.
про CSV отписался выше — стояла задача «одну кнопочку, чтобы было красиво»
Когда мне нужно было такое, я просто распарсил SpreadsheetML. Стандарт — открытый. Опыт у меня уже был (так парсил и ворд и ООо документ). Писать — пара тыщ строк кода, пара дней.
Это был последний вариант, если бы выложенный не сработал
Provider=Microsoft.ACE.OLEDB.12.0 — ещё хорошо бы упомянуть, откуда есть берётся этот провайдер БД (стандарный, с офисом ставится, отдельный).
4Гб оперативки и OutOfMemory никак не связаны — заканчивается 2Гб виртуального адресного пространства процесса.
Функция NewProcent очень порадовала =)

А Interop — штука для неторопливых, но иногда это единственный вариант. Делал через неё раскраску файлов (regexp'ами) — за несколько часов 40k строк отчёта переварила.
Когда дело доходит до форматирования — большинство сторонних открытых решений действительно не подходят. Мы в нашем софте в итоге, устав от тормозов и глюков особенностей Interop, обзавелись вот этой штукой. В работе с ней тоже есть нюансы, но в целом всё сильно упростилось.
В сторону NPOI не смотрели? Установки не требует, пара длл-ок и все. По скорости все устраивает (60к строк в xls пишет моментально), хотя настолько большие файлы как у автора обрабатывать не приходилось.
Sign up to leave a comment.

Articles