Счет-фактура в XML

Игорь Столяров

Лучше сразу включать XML.SetUseCRLF(False) - как в моем первом примере.
С точки зрения XML документа переносы значения не имеют, а красивое оформление для просмотра в текстовом редакторе, вообщем-то никому и не нужно. А в Explorer или любом редакторе XML документов - структура отображается правильно независимо от переносов.

Для меня конструкция "SAux1 &= SAux2[1:lSLen]" является синтаксическим маразмом.
Понятно, что в методе просто ляп, но по идее это ошибка и должна отсекаться компилятором ...

Сообщение **Admin** » 09 Ноябрь 2014, 10:59

Игорь Столяров писал(а):Лучше сразу включать XML.SetUseCRLF(False) - как в моем первом примере.
С точки зрения XML документа переносы значения не имеют, а красивое оформление для просмотра в текстовом редакторе, вообщем-то никому и не нужно. А в Explorer или любом редакторе XML документов - структура отображается правильно независимо от переносов.

По работе часто нужно лазить в XML, смотреть проще с переводом строк

Игорь Столяров писал(а):Для меня конструкция "SAux1 &= SAux2[1:lSLen]" является синтаксическим маразмом.
Понятно, что в методе просто ляп, но по идее это ошибка и должна отсекаться компилятором ...

Еще когда код смотрел обратил внимание на эту строку. Но не вдумывался

Игорь Столяров

К сожалению, вынужден констатировать что с ABPRXML - тоже не хорошо ...

При попытке выгрузить, файл с 20 000 записями, по 30 тегов в каждой записи - систематически GPF ...

И очень меееееееееедленно. Попробую сначала переписать на экспорт через драйвер ASCII-файла,
а потом можно и на прямой экспорт через WinAPI. Думаю, что это должно поднять скорость на порядок.
Принцип понятен, просто текстовый файл с заменой символов, а закрыть "ручками" тег мне не сложно.

kreator

Через Ascii-драйвер всё хорошо по скорости. Вот таких объёмов (20000 по 30) у меня не было ещё.

Игорь Столяров

Да, действительно. При переводе экспорта XML на ASCII драйвер скорость выросла ровно на порядок.

Несколько напрягает ограничение размера поля в 64K при экспорте секций CDATA с графикой и файлами (в ABPRXML то же есть это ограничение), а в остальном проблем нет. Попробую теперь переписать на DOS драйвер, а потом на WinApi ...

Игорь Столяров писал(а): DOS драйвер, а потом на WinApi

А в чём там может быть проблема? Я специально весь экспорт из программы запрятал в класс которому передаётся для записи строка. А там всё просто.

Игорь Столяров

Проблема в том, что если нужно записать в XML структуру данных длиной больше 64K - то через ASCII драйвер это нельзя сделать.
(Ограничение на размер записи в драйвере ASCII). Например какой-нибудь графический файл в секцию CDATA в BASE64 кодировке.
А через DOS драйвер это легко решается, и скорость записи выше чем ASCII.

А вот с записью файла через WinAPII - облом. Запись больших XML файлов (более 10 MByte) зависает намертво.
Разбираться не стал. DOS драйвер решил все проблемы (кстати через него же работает и библиотека iQXML).

Игорь Столяров писал(а): А вот с записью файла через WinAPII - облом. Больший XML файлы (более 10 MByte) зависают намертво.

Не сталкивался. У меня другая проблема - тормозить вывод для придания большей значимости (смотрите как тяжело всё это делается).

Правда, больше 2-3Мб не экспортировал ни разу. Но, в любом случае, хорошо то, что хорошо работает.

Игорь Столяров

По скорости формирования XML файла через DOS драйвер могу сказать следующее:
Размер XML файла 10 MByte, 350 000 строк в кодировке UTF-8, (20 000 записей по 15 тегов в каждой + заголовок)
Время формирования 60-70 сек. На мой взгляд - волшебно.

Через ABPRXML тот же файл формируется 15 минут и через раз GPF.

Игорь Столяров писал(а): ABPRXML тот же файл формируется 15 минут и через раз GPF

Самое забавное, что ABPRXML делает тоже через DOS

Код: Выделить всё

ReportTarget_InFile     FILE,DRIVER('DOS'),PRE(RT_IN),THREAD
                          RECORD
Buffer                     STRING(64000)
                          END
                        END
ReportTarget_OutFile    FILE,DRIVER('DOS'),CREATE,PRE(RT_OUT),THREAD
                          RECORD
Buffer                     STRING(64000)
                          END
                        END

Видимо, там масса проверок и лишнего кода.

Игорь Столяров

Да, я это видел. Но там куча разного кода по отслеживанию структуры вложенных тегов и
не реализована запись структур более размера записи (64K).
В принципе APRXML - предназначен для экспорта отчетов и с этим он вполне справляется.
Это я его пробовал "прикрутить" для формирования произвольных XML файлов большого размера.

kreator

По описанию DOS-драйвера в хелпе тоже есть ограничение на 64K, или это как-то обходится? Смотрел-смотрел на разницу в драйверах (DOS и ASCII), типа всё одинаково.

Игорь Столяров

Обходится легко. ASCII драйвер записывает после каждой записи перенос строки (в принципе можно отключить).
А в DOS - просто пишешь столько байт сколько нужно и при необходимости вручную формируешь перенос строки. Вот и все.

kreator

Т.е. всё равно пишешь 64K блоками, а где надо делаешь перенос строки?

Игорь Столяров

Игорь Столяров писал(а):Т.е. всё равно пишешь 64K блоками, а где надо делаешь перенос строки?

Абсолютно верно !

Кстати для XML файла переносы строк вообще не нужны (ну разве что для просмотра в тексте при отладке).
Поэтому просто запись тегов блоками с Clip(), а если тег больше 64K - то он записывается несколькими блоками. Вот и все.

forum.clarionlife.net