Foxpro выгрузка данных в excel
Я ищу, чтобы экспортировать таблицу из Visual Foxpro 5.0, чтобы преуспеть с общим для одного столбца. Я знаю, что вы можете рассчитать сумму (столбец), но я не знаю, как включить это в экспорт.
4 ответа
Я знаю, что вы можете рассчитать сумму (столбец), но я не знаю, как включить это в экспорт
Короткий ответ: ты не можешь.
Вы можете использовать команду VFP: COPY TO файл Excel XL5 , чтобы вывести данные в указанный файл Excel, но вычисленные значения не будут включены.
НО, после записи данных вы можете затем использовать VFP Automation of Excel, чтобы либо записать вычисленное значение в определенную ячейку, либо вы можете сделать так, чтобы Excel запустил вычисление для вас и поместил результат в указанную ячейку.
Если вы еще не сделали VFP Automation of Excel, вам может потребоваться Google для этого, поскольку он включает в себя ряд команд, которые должны варьироваться в зависимости от ваших конкретных потребностей.
Если вам это нужно в Excel, то зачем вообще суммировать? Excel умеет суммировать. Если вам действительно нужно, вы можете сделать это, просто создав курсор с добавленной строкой для хранения суммы. Что-то вроде:
Создание данных Excel из курсора / таблицы - более сложная часть, но есть много способов (то есть: просто копирование в виде файла с разделителями с заголовком, который вы создаете .CSV, который затем может быть открыт Excel). ИМХО одним из лучших способов является передача данных с использованием набора записей ADO. Вы можете искать код VFP2Excel в Интернете. Я написал и опубликовал много ее вариантов (я добавлю ссылку, если скоро ее найду - для VFP5 могут потребоваться небольшие изменения для команды \ функций, недоступной в VFP5).
(Или вы можете сделать это другим способом и напрямую получить данные из Excel, используя ADO - QueryTables).
OK нашел много ссылок, некоторые из них:
Вы можете использовать лист Excel в качестве шаблона. Затем заполните конкретные ячейки из FoxPro в этот шаблон и функции и форматирование в шаблоне будут работать с вашими данными.
Я подумал о другом способе получить вычисленную сумму в файл Excel, но это своего рода «кладж», и в файле Excel это действительно не будет динамический расчет, а вместо этого будет ячейка, которая может статически удерживайте вычисленное значение VFP.
Хорошо, вот "Kludge" .
Откройте таблицу данных VFP и выполните расчет итогов.
APPEND BLANK для добавления новой пустой записи и в одном из полей ЗАМЕНИТЕ ее значение на рассчитанную сумму.
Теперь выполните КОПИРОВАТЬ В Excel файл XL5
Все ваши данные будут записаны, и эти данные будут включать в себя ваш рассчитанный общий отчет с его значением.
ПРИМЕЧАНИЕ. Если необходимо, чтобы строки Excel находились в последовательности, отличной от исходной таблицы данных VFP, перед запуском COPY TO . выполните запрос SQL, чтобы получить все записи в нужном порядке, и запишите результаты в новый стол / курсор переписать.
Затем вы должны добавить пустую строку к результирующей таблице / курсору и использовать ее для копирования .
SYLK формата вполне хватает с минимальным форматированием - это же простой текстовый файл, кстати его нормально понимает ОО, как это меня в свое время сильно порадовало
------------------
Часто бывает так, что есть над чем задуматься, а нечем.
есть еще вариант с выгрузкой во временный экселешный файл и его загрузкой в эксель
ниже кусок из моего стандартного класса выгрузки данных в эксель, думаю, разберешься
Исправлено: AlexSSS, 28.06.10 13:20
По поводу формата Sylk - можно конечно но по мне, работа с ним не сильно отличается от того что бы сделать текстовый HTML файл и дать ему расширение XLS. Он тоже при открытии преобразовывается (правда HTML несколько медленнее SYLK, но зато можно отформатировать и раскрасить как нужно)
Второй вариант создание временного файла не подходит тем, что при копировании в формать XL5 теряется Memo поле, а иенно из за него весь сыр бор то и возник.Т.к. при копировании данных через массив именно большое мемо и создает проблеммы (но оно нужно полным без обрезания).
Я думал может кто то уже сталкивался с этим и победил.
Но похоже что ни кто такое мемо не таскает в эксел.
Придется предварительно проверять длину мемо поля и если она вылезет за 900 символов ставить признак что вылезла за пределы. дальше загружать в массив обрезанное мемо поле.
и вторым проходом уже в экселе заменять обрезанные мемо поля путем непосредственного введения данных в ячейку.
Не совсем представляю, для чего могут быть нужны такие отчеты. Разве что "для галочки".
Как вы с ними собираетесь работать?
------------------
Совершенство - это не тогда, когда нельзя
ничего прибавить, а тогда, когда нечего убавить.
Точно не уверен, но мне кажется имеет смысл покопать в литературе по Excel в сторону параметров задания числового формата содержимого, что заносится в ячейку. Возможно по умолчанию записываемое воспринимается как "короткий" вариант переменной?
------------------
В действительности все иначе, чем на самом деле.
(Антуан де Сент-Экзюпери)
По поводу не совсем представляю что за отчет.
Это списочные сведения к отчету. (т.е. отчет сам по себе содержит цифру), но эту цифру нужно расшифровывать, при этом оператор может выбрать поля выгружаемые в эксел, вот это и есть та самая расшифровка.
Более того оператор может открыть отчет в экселе (с цифровыми показателями) выбрать интересующую его ячейку с цифрой дважды щелкнуть ее, и должен сформироваться SQL запрос который и выдаст список в грид, а уже с грида оператор выводит в эксел. (там еще используется форматирование, объединение ячеек, т.е. записи из основеной таблицы показываются один раз а подчиненные не объединенными)
Так вот по поводу покопать параметры Экселя это конечно идея, ещеб найти этот параметр.
Исправлено: ЮК, 28.06.10 14:38
900 - это думаю зависит от конфигурации машины, но никак не самого экселя, не факт что глюк вылезит на других машинах с меньшей циферкой.
Как вариант решения - попробуй поставить одинарную кавычку "'" перед содержимым мемо поля - эксель в таком случае будет воспринимать данные однозначно как текстовые и не будет корячится что бы их преобразовать.
В данной статье рассматривется вопрос о том каким образом используя COM-объект записать данные из таблицы FoxPro в книгу Excel. Данный пример тестировался в FoxPro версии 9 и дать гарантию, что он будет работать в младших версиях программы дать не могу.
Конечно последняя версия FoxPro вышла в октябре 2007 года, а поддержка завершилась в январе 2015 года статья может быть полезна для тех кто использует FoxPro в работе.
И так приступим.
Прежде всего подключимся к таблице из которой надо переписать данные в Excel.
Далее локальную переменную и привязываем к ней MS Excel и создаем внём новый документ
в полученном документе создаем новую книгу
в полученной книге создаем новый лист и определяем для некоторых колонок ширину в символах, т.е. буквах
далее создаем шапку документа, т.е. в определенные ячейки записываем текст по примеру того, что приведен ниже
m.loSheet.Cells(1,1).Value = «Каное-то название»
m.loSheet.Cells(3,5).Value = "по учету расчетов с депонентами на года"
m.loSheet.Cells(4,13).Value = "Дата увольнения"
далее осуществляем считывание из таблицы данные и записываем в ячейки начиная с пятой строки указывая из каких столбцов таблицы считывать и в какие ячейки записывать
далее нам необходимо осуществить сортировку. В данном примере показана сортировка по двум столбцам - «Фамилия» и «Цеху». Для этого создаем три переменные
В первую переменную запишем координаты того участка таблицы EXCEL в котором не обходимо произвести сортировку. В данном случае задаются координаты левой верхней ячейки и правой нижней ячейки в выделенной области будет производиться сортировка
далее указываем столбцы по которым необходимо осуществлять сортировку
добавляем в метод сортировки как столбцы, по которым будет производиться сортировка, так и область в которой будет производиться сортировка
далее определяем ориентацию сортировки и метод сортировки (т.е. фактически в алфавитном порядке)
Есть в IT-отрасли задачи, которые на фоне успехов в big data, machine learning, blockchain и прочих модных течений выглядят совершенно непривлекательно, но на протяжении десятков лет не перестают быть актуальными для целой армии разработчиков. Речь пойдёт о старой как мир задаче формирования и выгрузки Excel-документов, с которой сталкивался каждый, кто когда-либо писал приложения для бизнеса.
Какие возможности построения файлов Excel существуют в принципе?
- VBA-макросы. В наше время по соображениям безопасности идея использовать макросы чаще всего не подходит.
- Автоматизация Excel внешней программой через API. Требует наличия Excel на одной машине с программой, генерирующей Excel-отчёты. Во времена, когда клиенты были толстыми и писались в виде десктопных приложений Windows, такой способ годился (хотя не отличался скоростью и надёжностью), в нынешних реалиях это с трудом достижимый случай.
- Генерация XML-Excel-файла напрямую. Как известно, Excel поддерживает XML-формат сохранения документа, который потенциально можно сгенерировать/модифицировать с помощью любого средства работы с XML. Этот файл можно сохранить с расширением .xls, и хотя он, строго говоря, при этом не является xls-файлом, Excel его хорошо открывает. Такой подход довольно популярен, но к недостаткам следует отнести то, что всякое решение, основанное на прямом редактировании XML-Excel-формата, является одноразовым «хаком», лишенным общности.
- Наконец, возможна генерация Excel-файлов с использованием open source библиотек, из которых особо известна Apache POI. Разработчики Apache POI проделали титанический труд по reverse engineering бинарных форматов документов MS Office, и продолжают на протяжении многих лет поддерживать и развивать эту библиотеку. Результат этого reverse engineering-а, например, используется в Open Office для реализации сохранения документов в форматах, совместимых с MS Office.
Но у прямого использования Apache POI есть и недостатки. Во-первых, это Java-библиотека, и если ваше приложение написано не на одном из JVM-языков, вы ей вряд ли сможете воспользоваться. Во-вторых, это низкоуровневая библиотека, работающая с такими понятиями, как «ячейка», «колонка», «шрифт». Поэтому «в лоб» написанная процедура генерации документа быстро превращается в обильную «лапшу» трудночитаемого кода, где отсутствует разделение на модель данных и представление, трудно вносить изменения и вообще — боль и стыд. И прекрасный повод делегировать задачу самому неопытному программисту – пусть ковыряется.
Но всё может быть совершенно иначе. Проект Xylophone под лицензией LGPL, построенный на базе Apache POI, основан на идее, которая имеет примерно 15-летнюю историю. В проектах, где я участвовал, он использовался в комбинации с самыми разными платформами и языками – а счёт разновидностей форм, сделанных с его помощью в самых разнообразных проектах, идёт, наверное, уже на тысячи. Это Java-проект, который может работать как в качестве утилиты командной строки, так и в качестве библиотеки (если у вас код на JVM-языке — вы можете подключить её как Maven-зависимость).
Xylophone реализует принцип отделения модели данных от их представления. В процедуре выгрузки необходимо сформировать данные в формате XML (не беспокоясь о ячейках, шрифтах и разделительных линиях), а Xylophone, при помощи Excel-шаблона и дескриптора, описывающего порядок обхода вашего XML-файла с данными, сформирует результат, как показано на диаграмме:
Шаблон документа (xls/xlsx template) выглядит примерно следующим образом:
Как правило, заготовку такого шаблона предоставляет сам заказчик. Вовлечённый заказчик с удовольствием принимает участие в создании шаблона: начиная с выбора нужной формы из «Консультанта» или придумывания собственной с нуля, и заканчивая размерами шрифтов и ширинами разделительных линий. Преимущество шаблона в том, что мелкие правки в него легко вносить уже тогда, когда отчёт полностью разработан.
Когда «оформительская» работа выполнена, разработчику остаётся
- Создать процедуру выгрузки необходимых данных в формате XML.
- Создать дескриптор, описывающий порядок обхода элементов XML-файла и копирования фрагментов шаблона в результирующий отчёт
- Обеспечить привязку ячеек шаблона к элементам XML-файла с помощью XPath-выражений.
Если бы в форме, которую мы создаём, не было повторяющихся элементов с разным количеством (таких, как строки накладной, которых разное количество у разных накладных), то дескриптор выглядел бы следующим образом:
Здесь root – название корневого элемента нашего XML-файла с данными, а диапазон A1:Z100 – это прямоугольный диапазон ячеек из шаблона, который будет скопирован в результат. При этом, как можно видеть из предыдущей иллюстрации, подстановочные поля, значения которых заменяются на данные из XML-файла, имеют формат
(тильда, фигурная скобка, XPath-выражение относительно текущего элемента XML, закрывающая фигурная скобка).
Что делать, если в отчёте нам нужны повторяющиеся элементы? Естественным образом их можно представить в виде элементов XML-файла с данными, а помочь проитерировать по ним нужным образом помогает дескриптор. Повторение элементов в отчёте может иметь как вертикальное направление (когда мы вставляем строки накладной, например), так и горизонтальное (когда мы вставляем столбцы аналитического отчёта). При этом мы можем пользоваться вложенностью элементов XML, чтобы отразить сколь угодно глубокую вложенность повторяющихся элементов отчёта, как показано на диаграмме:
Красными квадратиками отмечены ячейки, которые будут являться левым верхним углом очередного прямоугольного фрагмента, который пристыковывает генератор отчёта.
Есть и ещё один возможный вариант повторяющихся элементов: листы в книге Excel. Возможность организовать такую итерацию тоже имеется.
Рассмотрим чуть более сложный пример. Допустим, нам надо получить сводный отчёт наподобие следующего:
Пусть диапазон лет для выгрузки выбирает пользователь, поэтому в этом отчёте динамически создаваемыми являются как строки, так и столбцы. XML-представление данных для такого отчёта может выглядеть следующим образом:
Мы вольны выбирать названия тэгов по своему вкусу, структура также может быть произвольной, но с оглядкой на простоту конвертации в отчёт. Например, выводимые на лист значения я обычно записываю в атрибуты, потому что это упрощает XPath-выражения (удобно, когда они имеют вид @имяатрибута ).
Шаблон такого отчёта будет выглядеть так (сравните XPath-выражения с именами атрибутов соответствующих тэгов):
Теперь наступает самая интересная часть: создание дескриптора. Т. к. это практически полностью динамически собираемый отчёт, дескриптор довольно сложен, на практике (когда у нас есть только «шапка» документа, его строки и «подвал») всё обычно гораздо проще. Вот какой в данном случае необходим дескриптор:
Полностью элементы дескриптора описаны в документации. Вкратце, основные элементы дескриптора означают следующее:
- element — переход в режим чтения элемента XML-файла. Может или являться корневым элементом дескриптора, или находиться внутри iteration . С помощью атрибута name могут быть заданы разнообразные фильтры для элементов, например
- name="foo" — элементы с именем тэга foo
- name="*" — все элементы
- name="tagname[@attribute='value']" — элементы с определённым именем и значением атрибута
- name="(before)" , name="(after)" — «виртуальные» элементы, предшествующие итерации и закрывающие итерацию.
- mode="horizontal" — режим вывода по горизонтали (по умолчанию — vertical)
- index=0 — ограничить итерацию только самым первым встреченным элементом
- sourcesheet —лист книги шаблона, с которого берётся диапазон вывода. Если не указывать, то применяется текущий (последний использованный) лист.
- range – диапазон шаблона, копируемый в результирующий документ, например “A1:M10”, или “5:6”, или “C:C”. (Применение диапазонов строк типа “5:6” в режиме вывода horizontal и диапазонов столбцов типа “C:C” в режиме вывода vertical приведёт к ошибке).
- worksheet – если определён, то в файле вывода создаётся новый лист и позиция вывода смещается в ячейку A1 этого листа. Значение этого атрибута, равное константе или XPath-выражению, подставляется в имя нового листа.
Ну что же, настало время скачать Xylophone и запустить формирование отчёта.
Возьмите архив с bintray или Maven Central (NB: на момент прочтения этой статьи возможно наличие более свежих версий). В папке /bin находится shell-скрипт, при запуске которого без параметров вы увидите подсказку о параметрах командной строки. Для получения результата нам надо «скормить» ксилофону все приготовленные ранее ингредиенты:
Открываем файл report.xlsx и убеждаемся, что получилось именно то, что нам нужно:![]()
Так как библиотека ru.curs:xylophone доступна на Maven Central под лицензией LGPL, её можно без проблем использовать в программах на любом JVM-языке. Пожалуй, самый компактный полностью рабочий пример получается на языке Groovy, код в комментариях не нуждается:
У класса XML2Spreadsheet есть несколько перегруженных вариантов статического метода process , но все они сводятся к передаче всё тех же «ингредиентов», необходимых для подготовки отчёта.Важная опция, о которой я до сих пор не упомянул — это возможность выбора между DOM и SAX парсерами на этапе разбора файла с XML-данными. Как известно, DOM-парсер загружает весь файл в память целиком, строит его объектное представление и даёт возможность обходить его содержимое произвольным образом (в том числе повторно возвращаясь в один и тот же элемент). SAX-парсер никогда не помещает файл с данными целиком в память, вместо этого обрабатывает его как «поток» элементов, не давая возможности вернуться к элементу повторно.
Использование SAX-режима в Xylophone (через параметр командной строки -sax или установкой в true параметра useSax метода XML2Spreadsheet.process ) бывает критически полезно в случаях, когда необходимо генерировать очень большие файлы. За счёт скорости и экономичности к ресурсам SAX-парсера скорость генерации файлов возрастает многократно. Это даётся ценой некоторых небольших ограничений на дескриптор (описано в документации), но в большинстве случаев отчёты удовлетворяют этим ограничениям, поэтому я бы рекомендовал использование SAX-режима везде, где это возможно.
Надеюсь, что способ выгрузки в Excel через Xylophone вам понравился и сэкономит много времени и нервов — как сэкономил нам.
Читайте также: