DataSet & XML

← →
IronHawk © (2006-09-13 17:14) [0]

Модно ли читать (в,из) DataSet-а XML-данные?

← →
ANB © (2006-09-13 17:21) [1]

Я бы сказал - если не требует ТЗ, то нафиг надо.

← →
Reindeer Moss Eater © (2006-09-13 17:31) [2]

Но все равно однозначно - это очень модно.

← →
sniknik © (2006-09-13 17:48) [3]

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

← →
Reindeer Moss Eater © (2006-09-13 17:58) [4]

Жалко, что раньше не проверчивали.
А так глядишь - те же траблы с импортом/экспортом данных через dbase остались бы в прошлом веке.

← →
sniknik © (2006-09-13 18:19) [5]

с dbase у меня лично проблем было намного меньше чем с xml, хотя использую его для обмена намного дольше.
и не только его, нет, то что больше подходило, нужен текстовый файл значит будет он. а счас просто засилье какоето, xml обязывают использовать несмотря ни на что.
вот, вам не приходилось принимать как входные данные 2 гигабайтный xml? (и как только его сделали... открыть мы его так и не смогли, а там база, пара десятков таблиц... после того, как уговорили прислать ее в тексте она вся оказалась ~76мг. файлов... в архиве вообще смешной размер)

← →
Другой © (2006-09-13 19:13) [6]

Если есть возможность, то можно доверить серверу:

CREATE PROCEDURE tmp_ImportFile @Body text=NULL AS SET NOCOUNT ON CREATE TABLE #exportfile ( ef_pk int identity primary key, ef_count int, ef_name varchar(50), ef_fromname varchar(200), ef_fromcode varchar(5) ) DECLARE @idoc int EXEC sp_xml_preparedocument @idoc OUTPUT, @Body INSERT #exportfile ( ef_count, ef_name, ef_fromname, ef_fromcode ) SELECT * FROM OPENXML (@idoc, "/exportfile",1) WITH ( ef_count int "@count", ef_name varchar(50) "@name", ef_fromname varchar(200) "@fromname", ef_fromcode varchar(5) "@fromcode" ) EXEC sp_xml_removedocument @idoc SELECT * FROM #exportfile

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

← →
ANB © (2006-09-13 19:30) [7]

> Другой © (13.09.06 19:13) [6]
> Если есть возможность, то можно доверить серверу:

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

← →
Reindeer Moss Eater © (2006-09-13 19:33) [8]

с dbase у меня лично проблем было намного меньше чем с xml, хотя использую его для обмена намного дольше.

У меня с моими дибейсами тоже проблем нет. Как и у любого другого с его дибейсами.
Проблемы начинаются когда люди начинают обмениваться своими дибейсами друг с другом. И вот тогда на ровном месте можно получить немало проблем.

← →
Другой © (2006-09-13 19:37) [9]

ANB © (13.09.06 19:30) [7]

Столько записей не пробовал ;)

← →
AlexWlad © (2006-09-13 19:37) [10]

> Reindeer Moss Eater © (13.09.06 19:33) [8]

Проблемы начинаются, когда делаешь из дибейза - свой дибейз. Стандарты еще никому не вредили.

← →
ANB © (2006-09-13 19:39) [11]

> Другой © (13.09.06 19:37) [9]

А ты попробуй. И посмотри размер XML. Особливо, если полей в табличке много и все они не сильно длинные.

← →
Reindeer Moss Eater © (2006-09-13 19:44) [12]

Проблемы начинаются, когда делаешь из дибейза - свой дибейз. Стандарты еще никому не вредили.

Ты вообще в курсе, сколько там стандартов?

← →
Другой © (2006-09-13 19:45) [13]

ANB © (13.09.06 19:39) [11]
А ты попробуй. И посмотри размер XML. Особливо, если полей в табличке много и все они не сильно длинные.

А зачем? Я выдрал кусок из работающего кода.

Хотя нет, щас попробую.
Особливо, если полей в табличке много и все они не сильно длинные.
Много эт сколько?

← →
Reindeer Moss Eater © (2006-09-13 19:47) [14]

И если в нашей табличке будет хотя бы миллиончика 2 записей, то на импорте серверу резко поплохеет

Это уже смахивает не на импорт/экспорт, а на миграцию данных схемы.

← →
Reindeer Moss Eater © (2006-09-13 19:50) [15]

Есть вещи по настоящему вредные. И xml отнюдь не в их числе.
Юникод, например, точно изобрели пособники диавола.
Символ должен быть байтом!

← →
AlexWlad © (2006-09-13 19:51) [16]

> Reindeer Moss Eater © (13.09.06 19:44) [12]

Не так уж и много. Основная беда с индексами - там да, наизвращались... С другой стороны при экспорте/импорте индексы малополезны.

← →
Другой © (2006-09-13 19:53) [17]

Модно ли читать (в,из) DataSet-а XML-данные?

Только заметил :)

← →
Reindeer Moss Eater © (2006-09-13 19:56) [18]

AlexWlad ©

Вот есть контора. И вы обязаны с ней работать в силу того, что она некий федеральный институт власти. И обязаны осуществлять обмен с ней.
А в конторе используется dbase c символьными полями длиной 256 букв.
Попробуй создай такой файл не средствами досовского клиппера или еще какой экзотики используемой в той конторе.
Это только один пример коих можно привести множенство (если иметь богатый опыт реальной работы)

← →
ANB © (2006-09-13 20:24) [19]

> не средствами досовского клиппера

Эт ты загнул. У клиппера длина символьных полей до 64К.

Но вообще то, если писать в DBF, как в файл и аккуратно работать со структурой, то проблем не возникнет.

← →
AlexWlad © (2006-09-13 20:25) [20]

Ну что такого страшного в строках длиной 256 символов? Про "короткие" строки давно пора забыть. Написать класс для работы с файлом напрямки - 1 час.

← →
sniknik © (2006-09-13 20:53) [21]

Reindeer Moss Eater © (13.09.06 19:56) [18]

вот есть контора. и вы обязаны с ней работать в силу того, что она некий федеральный институт власти. и обязаны осуществлять обмен с ней.
а в конторе используется xml cо структурой строго по учебнику...
например отсюда (хотя понимаю это не учебник ;)
http://ru.wikipedia.org/wiki/XML#.D0.A1.D0.B8.D0.BB.D1.8C.D0.BD.D1.8B.D0.B5_.D0.B8_.D1.81.D0.BB.D0.B0.D0.B1.D 1.8B.D0.B5_.D1.81.D1.82.D0.BE.D1.80.D0.BE.D0.BD.D1.8B
и попробуй создай такой файл, и именно стандартными средствами... или хотябы прочитай. (скопируй пример в созданный текстовый файл, переименуй с расширением xml и открой IE... ты не открываеш их, они твой, как же так xml же средство обмена, его все понимают. или всетаки нет?)
это только один пример коих можно привести множенство (если иметь богатый опыт реальной работы)

p.s. не надо выдумывать "страшилок" жизнь и без них веселая.
p.p.s. ну работают они с такими таблицами, причем здесь обменные? принесеш в dBase, под dos естественно, "экзотический" клипер его сьест и не подавится.
а раз вы работаете не под ним, то данных размером больше 255 символов у вас нет... (ну или будеш подгонять. чего страшного?)

← →
Другой © (2006-09-13 21:17) [22]

sniknik © (13.09.06 20:53) [21]

1.
Вы либо попробуйте сохранить в UTF-8,
например редактором akelpad.

2.
Либо замените в "шапке" примера:
<?xml version="1.0" encoding="UTF-8"?>
на
<?xml version="1.0" encoding="windows-1251"?>
раз уж сохраняете в виндовой кодеровке.

оба варианта работают.

В данном случае "стандартные средства" не причем.

← →
Другой © (2006-09-13 21:20) [23]

sniknik © (13.09.06 20:53) [21]

Аа, понял о чем Вы.
:)

← →
kaif © (2006-09-14 00:15) [24]

XML не зависит от платформы

О платформы не зависит только бумажный документ.
Положил его на платформу, а сверху - рыбу и пиво.

← →
Reindeer Moss Eater © (2006-09-14 09:40) [25]

Эт ты загнул. У клиппера длина символьных полей до 64К.

Но вообще то, если писать в DBF, как в файл и аккуратно работать со структурой, то проблем не возникнет.

Я и не утверждал, чт оэто именно клиппер. И у клиппера 64к - это мемо поля. А символьные - 256 символов.
И файл этот открывается и заполняется средствами БДЕ без проблем.
Этот файл не создается средствами БДЕ.

Мне приходилось зашивать в ресурсы пустую болванку и выгружать её на диск.

И это только один пример как было уже сказано.

Недавно здесь кайф пытался побороть странный дбф в заголовке у которого одно, а в реале другое.
И примеров таких - множество.

А тот пример из википедии действительно решается обычным AddProcessingInstruction.

← →
Reindeer Moss Eater © (2006-09-14 09:42) [26]

Ну что такого страшного в строках длиной 256 символов?

В строках ничего страшного нет. И в полях тоже нет за исключением того, что их так просто не создашь.

← →
sniknik © (2006-09-14 11:56) [27]

> Этот файл не создается средствами БДЕ.
т.е. это вообще просто какойто их внутренний файл просто (возможно случайно) имеющий расширение dbf? ....
ну допустим так, все одно непонятно какое отношение имеет используемый их программой формат и формат обменных файлов? внутренний это их внутреннее дело, а с обменными, это должно строго оговариваться. или бардак... и никакой разници с xml, те же самые проблемы, только помноженные на миф о том, что это универсальный формат обмена данными.

> А тот пример из википедии действительно решается обычным AddProcessingInstruction.
а зачем мне это решать если это якобы универсально?

> Недавно здесь кайф пытался побороть странный дбф в заголовке у которого одно, а в реале другое.
не совсем так, насколько понял у него там основная проблема в том, что пришли вперемешку файлы фокса(который как раз и пишет невзирая на байт в заголовке) и дбейса с кодировками и в дос и в "вин".
это не проблема формата, это организационная. если сказано четко, обмен ведется в dBase IV под дос, то проблем не будет. (а если еще и не пытаться использовать не приспособленную для этого вещь... ммм, вообще сказка будет.)

а вот тут к примеру
http://delphimaster.net/view/1-1158062383/
решается проблема с xml. (или все таки нет? ;о)) что это доказывает? а поиспользуют пару ~ десятков лет как dbf, таких проблем накопится и поболее чем с ним.

← →
Reindeer Moss Eater © (2006-09-14 12:02) [28]

внутренний это их внутреннее дело,

Это их внутреннее дело и чья-то объективная реальность данная в ощущениях. Есть файл и это DBASE. Сделанный в известной с древних времен dbu.exe.

И все.
Равняйсь-смирно, использовать его для обмена.

Такие же файлы как у кайфа делает 1С. Данные в ОЕМ а в заголовке не ОЕМ.

← →
stud © (2006-09-14 12:06) [29]

а где почитать про работу с xml в delphi7
вот тоже привалило счастье.
не укажите на источники, желательно в электронном виде

← →
sniknik © (2006-09-14 12:44) [30]

> И все.
> Равняйсь-смирно, использовать его для обмена.
чем это отличается от того, с чего начали только в отношении к xml?

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

> Такие же файлы как у кайфа делает 1С. Данные в ОЕМ а в заголовке не ОЕМ.
не проблема. даже если менять байт... (вернее сделать реструктуризацию стандартными средствами BDE), но лучше открыть тем движком который действует аналогично.

stud © (14.09.06 12:06) [29]
> не укажите на источники, желательно в электронном виде
http://www.google.ru/search?q=%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0+%D1%81+xml+%D0%B2+delphi7&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:ru:official

← →
Reindeer Moss Eater © (2006-09-14 12:55) [31]

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

теперь представь, что тебе надо не читать такой файл, а писать такой файл.
Пишем как обычно, потом портим байт.
Что бы проверить/посмотреть перед отправкой надо снова байт исправить и потом снова испортить.

В общем во многая дибейсах многая печаль.
А xml он один.
А про юникод я уже высказался. Это изобретение диавола.

← →
Reindeer Moss Eater © (2006-09-14 13:19) [32]

а вот тут к примеру
http://delphimaster.net/view/1-1158062383/
решается проблема с xml. (или все таки нет? ;о)) что это доказывает? а поиспользуют пару ~ десятков лет как dbf, таких проблем накопится и поболее чем с ним.

Эксперимент показал, что проблема не связана ни с xml ни с разделителем в системе.

← →
ANB © (2006-09-14 14:17) [33]

> А символьные - 256 символов

У клиппера обычные символьные поля могут быть до 64К.

Если это и так, то это еще один аргумент не в пользу DBase.

> теперь представь, что тебе надо не читать такой файл, а
> писать такой файл.

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

А вот распарсить XML объемом более 2-х метров - это уже довольно проблематично. Запись еще куда ни шло - можно просто в виде текста сгенерить. А вот писать самому парсер - повесишься. И использовать готовый - грести все его грабли.

Ну я например давно гоняю между клиентом и сервером мегабайтные xml пакеты клиентдатасета. В каком месте там зарыты грабли?

> теперь представь, что тебе надо не читать такой файл, а писать такой файл.
не только представлю, а много раз этим и занимался.

> А xml он один.
да ну? а зачем тогда в начале, в заголовке интерфейсная запись о системном парсере? и что будет если твой парсер отличается от задекларированного/с другой интерпретацией, или отсутствует в системе?

я скажу что будет, будет проблема... и если ты с таким столкнешся то так просто как с dbf не решиш (dbf будеш вспоминать как добрые старые безоблачные времена...).
для примера возми ClientDataSet загрузи данные, и выгрузи в файл (метод savetofile вроде бы) формат естественно xml, после возми ADODataSet и попробуй этот файл загрузить(у него похожая функциональность). получилось?
а как же универсальность? как же один?
и это не единственные интерпретации, у нас сишники используют какойто парсер "от основателя и идейного лидера xml", так вот он не понимает сделаного мелкософтским DOM-документом, когда начинаеш "как же так?" основной их аргумент "у мелкософта неправильный xml! они стандартов не поддерживают, и не только с xml"... а мне что до этого? мне обещали универсальность, а в итоге самое беспроблемное это свой парсер который меняется для каждого конкретного случая... так чтоли?
причем наверняка есть и другие... например (по аналогии dbf со "сбитой" кодировкой) которые не обращают внимания на кодировку вначале (как пример из википедии).
почему вообще ты замечаеш недостаток одного, а на аналогичное друогого не обращаеш внимания (типа "а, это легко решить", да, но и у другого тоже решается, легко, а то и еще легче...)

===========================
афоризм для фанатов (неважно чего).
Чем сильней горит сердце, тем слабей варит котелок.

Ой вот только не надо.
Не надо.

Я не парсю клиентдатасетом xml документы.
Клиентдатасет был упомянут в связи с мифическими граблями которые якобы появляются при двухмегабайтных xml файлах.

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

> Reindeer Moss Eater © (14.09.06 16:35) [38]

Попробуй тогда метров 20. А 2 - это ЦБР отказывается принимать пакеты большего размера.

Подозреваю, что когда у меня это получится, мне предложат грузануть файл в 20 гигабайт.

В чем проблема-то?
Два мегабайта, 20 мегабайт.....
Я буду использовать парсер который не загружает DOM целиком в память, а просто генерит события. Сколькто там уровней вложенности в датапакете?

PS Да хоть 20 терабайт.

> Я буду использовать парсер который не загружает DOM целиком
> в память

У тебя есть такой с исходниками ?

Ну вот например (например!!!!) фриварный от TurboPower на sourceforge.

ИМХО.

Поработав с XML я сделал вывод - буду его использовать для обмена только с такими корреспондентами, с которыми по другому нельзя.

Парсер надо либо ставить, либо мучится с тем, что есть (и со всеми глюками). Более менее приличный парсер - XMLType у оракла. Но умные люди говорили мне, что на больших файлах он таки тормозит.
Объем файла возрастает минимум вдвое, по сравнению с тем же DBF или текстовым файлом.
Возможности XML по запихиванию внутрь сложных структур данных практически нивелируются сложностью доставания этих данных.

> для обмена только с такими корреспондентами, с которыми по другому нельзя.
было бы это для меня возможно, без навязываний, ничего против xml-я не имел бы...

С dBase IV никаких проблем, даже Эксель в состоянии создавать его, а не то что читать. Проблемы когда под маркой dBase IV подсовывают, что которое таким не является. И хуже если это, что то Клиппер подобное, когда текстовые поля превышают 254 символа.

Для импорта экспорта XML один из худших вариантов, пришлось. Столкнуться пришлось, когда решили сделать экспорт из базы ФоксПро в базу на MS SQL, через неделю работы машину выключили и сделали за два часа экспорт через dbf
За время экспорта, через XML, размер файла подкачки несколько раз увеличивался, пока не достиг 1.5 гб. Размер сгенерировано файла, на момент прерывания достигал нескольких гигабайт, при общем размере базы в 100 мегабайт.

Ну ладно, вернемся к теме, нашего железного орла интересовало модно или нет. Еще как модно, можешь не сомневаться. И не верь словам насчет универсальности, переносимости - это всего лишь маркетинговый шум.

Эксель и DbaseIV?

Я я! Натюрлих.
Проблема действительно не в самом дибейсе, а в кажущейся всем подряд его простоте.
Мне приходилось воевать с дибейсом сделанным в экселе.
Была у людей таблица, они сделали save as.
Забыли только перед этим расширить нужные колонки.
Результат - одна строка/запись экселя расползалась по N записям Dbase файла.
Везде где wordwrap случился.

DataSet &amp; XML Найти похожие ветки

DataSet & XML Найти похожие ветки