Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

DataSet & XML [D6, D7, MSSQL]


Страницы:   1 2 3

IronHawk ©   (2006-09-13 17:14:00) 

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


Reindeer Moss Eater   (2006-09-15 08:23:00) [1]

Эксель и DbaseIV?

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


Anatoly Podgoretsky   (2006-09-14 20:15:00) [2]

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

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

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


sniknik   (2006-09-14 19:55:00) [3]

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


ANB   (2006-09-14 19:28:00) [4]

ИМХО.

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

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


Reindeer Moss Eater   (2006-09-14 19:25:00) [5]

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


ANB   (2006-09-14 19:23:00) [6]


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

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


Reindeer Moss Eater   (2006-09-14 19:21:00) [7]

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

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

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


ANB   (2006-09-14 18:32:00) [8]


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

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


Reindeer Moss Eater   (2006-09-14 16:41:00) [9]

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


Reindeer Moss Eater   (2006-09-14 16:35:00) [10]

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

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


sniknik   (2006-09-14 16:19:00) [11]

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

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

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

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


Reindeer Moss Eater   (2006-09-14 14:33:00) [12]

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


ANB   (2006-09-14 14:23:00) [13]


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

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

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


Reindeer Moss Eater   (2006-09-14 14:19:00) [14]

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


ANB   (2006-09-14 14:17:00) [15]


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

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


Reindeer Moss Eater   (2006-09-14 13:19:00) [16]

а вот тут к примеру
http://delphimaster.ru/cgi-bin/forum.pl?id=1158062383&n=0
решается проблема с xml. (или все таки нет? ;о)) что это доказывает? а поиспользуют пару ~ десятков лет как dbf, таких проблем накопится и поболее чем с ним.


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


Reindeer Moss Eater   (2006-09-14 12:55:00) [17]

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

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

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


sniknik   (2006-09-14 12:44:00) [18]

> И все.
> Равняйсь-смирно, использовать его для обмена.
чем это отличается от того, с чего начали только в отношении к 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


stud   (2006-09-14 12:06:00) [19]

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


Reindeer Moss Eater   (2006-09-14 12:02:00) [20]

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

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

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

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


Страницы:   1 2 3

Наверх

Титульная страница Поиск, карта сайта Написать письмо