Здравствуйте dad, Вы писали:

dad>Как вы оцениваете вариант использования в качестве хранилища (БД) XML файло?
dad>Программа предполагается достаточно большой (я имею ввиду объем данных),
dad>но работа с данными не очень оперативная. Типичное учетно-аналитичекое приложение..

Мой Вам совет: даже и не думайте об этом! Да, xml сейчас очень популярен. Но он разработан не для хранения данных, а для унифицированного обмена данными между различными приложениями.

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

Заметьте, разницы никакой! Но простой файл — это не база данных и уж тем более не СУБД. Вам придется написать кучу кода для доступа к этому файлу, сохранения изменений, обеспечения последовательного (хотя бы) одновременного доступа нескольких пользователей, аналог транзакций и т.д. — т.е. Вам придеться написать свою свою СУБД (!).

Зачем? Вы хотите унификации, простого переноса приложений, простую замену компонент?Так используйте технологии, которые позволят это сделать, например, в Вашем случае — OLE DB/ADO. И подключайте свое приложение сегодня к MS SQL, а завтра к бесплатному Interbase не меняя при этом ни строчки кода.

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

Удачи!

Здравствуйте Андрей Булат, Вы писали:

АБ>Здравствуйте коллеги (извините, что вмешиваюсь)
Прошу считать мелкой гнусной шуткой: коллеги?

АБ>Мне представляется, что:
АБ>1. Использовать XML в качестве носителя данных можно, если
АБ> 1.1. Хранящаяся информация в настоящий момент не имеет строго определенного формата (например — надо хранить характеристики игрушек, подъемных кранов, чего-нибудь еще (о чем сейчас не знаем)) — скорее учетное приложение
Все-равно о данных нужно что-то знать. Как об игрушках, так и о подъемных кранах нужны какие-то конкретные характеристики. Преимуществ у XML нет.

АБ> 1.2. Не требуется полная статистика по всему !!! массиву данных.
Не слишком понял, что Вы имели в виду.

АБ> 1.3. Не существует больших !!! XML файлов, а много маленьких
ЭТО ПРОСТО УЖАСНО! Управлять большим количеством маленьких файлов, чем бы они там не были. Уж лучше я их один раз загоню в БД и они у меня все будут под рукой. И я с ними со всеми что захочу то и сделаю. А постоянно "импрувить" файловые операции — это жестоко!

АБ>2. В этом случае у Вас может быть база-реестр (реляционная скорее всего (MSDE — хороший вариант)) хранящихся документов и их основных характеристик (например стоимость, тип ...) с возможностью поиска нужных XML документов (содержащих полные спецификации). Выбранный документ будет обрабатываться клиентским приложением (к вопросу о ресурсах сервера).
Сразу же вопрос: что мешает сложить все XML-документы в ту же БД? В чем выгода их туда не складывать?

АБ>3. Абсолютно согласен со всем, что сказал paul_shmakov (в особенности о популярности)
Тогда к чему ваши аргументы?

АБ>4. В дополнение, относительно импорта-экспорта. XML может быть хорошим вариантом при сборе информации (почти одинаковый код для получения данных по Internet, эл.почте, может сами, что-нибудь еще придумаете)
В целом это и есть импорт-экспорт. А как насчет репликации посредством XML? С клиентами на Palm OS например? (Навскидку ничего экстравагантного и в то же время практичного в голову не пришло).

АБ>5. Написать свой собственный полноценный сервер гораздо дороже (за работу надо платить), чем купить готовый
А вот с этим уже довольно интересно поспорить. Особенно если рассматривать "свой собственный сервер" не как "полноценный сервер БД", а как своего рода Middleware — а вот кто там за этой прослойкой — XML, MS SQL, Oracle или еще кто пострашнее — это "конечного клиента" никогда волновать не будет. Но похоже что мы придем к написанию ADO... Не совсем, конечно, но что-то похожее в этом есть.

АБ>PPS. С удовольствием пообщался-бы с paul_shmakov (?) (мой адрес andrewbulat@hotmail.com)
P.S. С не меньшим удовольствием пообщаюсь со всеми на эту тему. Мой адрес в профиле.

G>>Вы правы, доступ естественно параллельный. Но вот файлы-то большие, или Вы не согласны?
dad>я не согласен с тем, что весь файл закачивается в память. Закачиваются в память элементы (таблицы) используемые в запросе. Или я не прав? Как вы считаете? И при чем тут параллельный доступ?
Жесткий диск, да будет вам известно, разбит на сектора. Естественно, сектора приходится читать в память, чтобы прочитать файл. Теперь понятно?

PS: Изучите сначала устройство ЭВМ.

Как вы оцениваете вариант использования в качестве хранилища (БД) XML файло?
Программа предполагается достаточно большой (я имею ввиду объем данных),
но работа с данными не очень оперативная. Типичное учетно-аналитичекое приложение..
---------
плюсы:
— наличие бесплатных парсеров
соответсвенно низкая конечная стоимость и отсутсвие проблем с редистрибьюцией.

Здравствуйте dad, Вы писали:

dad>плюсы:
dad>- наличие бесплатных парсеров
dad>соответсвенно низкая конечная стоимость и отсутсвие проблем с редистрибьюцией.

минус — отсутствие поддержки совместного доступа к данным

хотя описательную часть можно вести и на access

РГ>минус — отсутствие поддержки совместного доступа к данным

РГ>хотя описательную часть можно вести и на access
конечно, я забыл сказать, предполагается написание собственного предметноориентированного
сервера, или какого-нить примитивного механизма блокировок.
например, DCOM сервер?

Здравствуйте dad, Вы писали:

РГ>>минус — отсутствие поддержки совместного доступа к данным

РГ>>хотя описательную часть можно вести и на access
dad>конечно, я забыл сказать, предполагается написание собственного предметноориентированного
dad>сервера, или какого-нить примитивного механизма блокировок.
dad>например, DCOM сервер?

Ню-ню!!! Времени у Вас что-ли полные карманы?

Здравствуйте dad, Вы писали:

dad>Как вы оцениваете вариант использования в качестве хранилища (БД) XML файло?
dad>Программа предполагается достаточно большой (я имею ввиду объем данных),
dad>но работа с данными не очень оперативная. Типичное учетно-аналитичекое приложение..

Используй простой расчёт — на каждый байт в XML файле тебе понадобится 10 в памяти.
А теперь прикинь, если файл будет 10 MB, то запасись 100 MB оперативки, если 40 MB, то...

dad>плюсы:
dad>- наличие бесплатных парсеров
dad>соответсвенно низкая конечная стоимость и отсутсвие проблем с редистрибьюцией.

Тогда бери mdb формат, ADO тоже штука бесплатная.

минусы:
— сомнительная надёжность
— однопользовательский режим

Здравствуйте VVP, Вы писали:

VVP>Здравствуйте dad, Вы писали:

РГ>>>минус — отсутствие поддержки совместного доступа к данным

РГ>>>хотя описательную часть можно вести и на access
dad>>конечно, я забыл сказать, предполагается написание собственного предметноориентированного
dad>>сервера, или какого-нить примитивного механизма блокировок.
dad>>например, DCOM сервер?

VVP>Ню-ню!!! Времени у Вас что-ли полные карманы?

т.е еще один минус — время разработки , но это скорее не к теме сабжа

Здравствуйте IT, Вы писали:
IT>Используй простой расчёт — на каждый байт в XML файле тебе понадобится 10 в памяти.
IT>А теперь прикинь, если файл будет 10 MB, то запасись 100 MB оперативки, если 40 MB, то...
довод весомый. Надо будет думать о разбиении информации на меньшие блоки а это уже гемморой..

IT>Тогда бери mdb формат, ADO тоже штука бесплатная.
?? поясни , если можешь.

Здравствуйте dad, Вы писали:

IT>>Тогда бери mdb формат, ADO тоже штука бесплатная.
dad>?? поясни , если можешь.

Постараюсь
Берёшь Access, создаёшь в нём базу (таблички там всякие, вьюшки), получаешь файлик mdb. Для доступа к базе можно использовать ADO, которая поставляется с офисом и другими приложениями от MS. В любом случае, не помешает скачать с сайта MS последнюю версию MDAC http://www.microsoft.com/data/download.htm.

IT>Здравствуйте dad, Вы писали:

IT>>>Тогда бери mdb формат, ADO тоже штука бесплатная.
dad>>?? поясни , если можешь.

IT>Постараюсь ;)
IT>Берёшь Access, создаёшь в нём базу (таблички там всякие, вьюшки), получаешь файлик mdb. Для доступа к базе можно использовать ADO, которая поставляется с офисом и другими приложениями от MS. В любом случае, не помешает скачать с сайта MS последнюю версию MDAC http://www.microsoft.com/data/download.htm.
-----------
спасибо, можно было и без стеба. Я имел ввиду бесплатность этих решений. Для редистрибьюции требуется приобрести к-ть программное обеспечение производства корпорации микрософт. А мне это совершенно не требуется. Как избежать таких ограничений?

Итак, позволю себе вступить с Вами в дискуссию:

По поводу размера:
1. В памяти всё равно приходится хранить mdb файлы, иначе, как его читать?
2. Соответствующие структуры данных также приходиться хранить в памяти. Т.е. вы всё равно
загружаете файлы в память, что из БД, что из XML.
Следовательно, XML более предпочтителен, чем БД.

Если что неясно, спрашивайте.


dad>Как вы оцениваете вариант использования в качестве хранилища (БД) XML файло?
dad>Программа предполагается достаточно большой (я имею ввиду объем данных),
dad>но работа с данными не очень оперативная. Типичное учетно-аналитичекое приложение..
dad>---------
dad>плюсы:
dad>- наличие бесплатных парсеров
dad>соответсвенно низкая конечная стоимость и отсутсвие проблем с редистрибьюцией.

G>По поводу размера:
G>1. В памяти всё равно приходится хранить mdb файлы, иначе, как его читать?
G>2. Соответствующие структуры данных также приходиться хранить в памяти. Т.е. вы всё равно
G>загружаете файлы в память, что из БД, что из XML.
G>Следовательно, XML более предпочтителен, чем БД.
Я не разделяю вашу уверенность в том, что в памяти необходимо держать весь файл. Скорее всего к-нть дао использует последовательный доступ. При работе по сети , да. Или я заблуждаюсь?

G>>Следовательно, XML более предпочтителен, чем БД.
dad>Я не разделяю вашу уверенность в том, что в памяти необходимо держать весь файл. Скорее всего к-нть дао использует последовательный доступ. При работе по сети , да. Или я заблуждаюсь?
Вы правы, доступ естественно параллельный. Но вот файлы-то большие, или Вы не согласны?

G>Вы правы, доступ естественно параллельный. Но вот файлы-то большие, или Вы не согласны?
я не согласен с тем, что весь файл закачивается в память. Закачиваются в память элементы (таблицы) используемые в запросе. Или я не прав? Как вы считаете? И при чем тут параллельный доступ?

G>Жесткий диск, да будет вам известно, разбит на сектора. Естественно, сектора приходится читать в память, чтобы прочитать файл. Теперь понятно?

G>PS: Изучите сначала устройство ЭВМ.
я ознакомился. Но дело в том, что доступ к файлам бывает последовательный я произвольный. Поэтому в память можно читать не весь файл а некоторые участки. Спросите у фигурнова.

IT>Используй простой расчёт — на каждый байт в XML файле тебе понадобится 10 в памяти.
IT>А теперь прикинь, если файл будет 10 MB, то запасись 100 MB оперативки, если 40 MB, то...
IT>Тогда бери mdb формат, ADO тоже штука бесплатная.

IT>минусы:
IT>- сомнительная надёжность
IT>- однопользовательский режим

Конечно есть такие требования к хранилищу как:
избыточность
скорость
требования к памяти
целостность
параллельный доступ
--------
но если я все равно буду писать свой сервер, например. То чем тогда отличается dbf или mdb? Говорят MDB может так упасть, что никакое адо его не прочитает.
ВО! вот так надо поставить вопрос:

помогите мне выбрать:
XML — XML-parser
DBF — DBF-api
MDB — DAO (ADO?)

Здравствуйте IT, Вы писали:

IT>Здравствуйте dad, Вы писали:

IT>>>Тогда бери mdb формат, ADO тоже штука бесплатная.
dad>>?? поясни , если можешь.

IT>Постараюсь
IT>Берёшь Access, создаёшь в нём базу (таблички там всякие, вьюшки), получаешь файлик mdb. Для доступа к базе можно использовать ADO, которая поставляется с офисом и другими приложениями от MS. В любом случае, не помешает скачать с

Гы, одного ADO маловато будет. Да и без него можно при желании обойтись. По минимуму нужен только Jet.

>сайта MS последнюю версию MDAC http://www.microsoft.com/data/download.htm.

PS. А почему про MSDE ни слова? Он же тоже бесплатный и возможностей у него побольше, чем у Access.

L>PS. А почему про MSDE ни слова? Он же тоже бесплатный и возможностей у него побольше, чем у Access.
по поводу МСДЕ — мне тут обратили внимание, на "подарок от микрософт", который хочет:
Computer with a Pentium 166-MHz or higher processor
Windows 98, Windows Me, Windows NT Workstation 4.0 with Service Pack 5 or later, Windows NT Server 4.0 with Service
Pack 5 (SP5) or later, Windows NT version 4.0 Server Enterprise Edition with SP5 or later, Windows 2000 Professional,
Windows 2000 Server, Windows 2000 Advanced Server, or Windows 2000 Datacenter Server operating system
Minimum of 32 megabytes (MB) of RAM. (64 MB or more is recommended. Additional memory may be required, depending on
operating system requirements.)
44 MB of available hard disk space
---------------------------------------
как Вам такой подарок?

Здравствуйте Gont, Вы писали:

G>Итак, позволю себе вступить с Вами в дискуссию:

G>По поводу размера:
G>1. В памяти всё равно приходится хранить mdb файлы, иначе, как его читать?

Бред. В память считываются только нужные в данный момент части файла. Ты себе можешь представить считывание 2Gb-ного акцессного файла в память на машине с 128 метрами памяти?

G>2. Соответствующие структуры данных также приходиться хранить в памяти. Т.е. вы всё равно
G>загружаете файлы в память, что из БД, что из XML.
G>Следовательно, XML более предпочтителен, чем БД.

Вот XML в память грузится целиком, поскольку его парсить нужно.

Здравствуйте dad, Вы писали:

L>>PS. А почему про MSDE ни слова? Он же тоже бесплатный и возможностей у него побольше, чем у Access.
dad>по поводу МСДЕ — мне тут обратили внимание, на "подарок от микрософт", который хочет:
dad>Computer with a Pentium 166-MHz or higher processor
dad>Windows 98, Windows Me, Windows NT Workstation 4.0 with Service Pack 5 or later, Windows NT Server 4.0 with Service
dad>Pack 5 (SP5) or later, Windows NT version 4.0 Server Enterprise Edition with SP5 or later, Windows 2000 Professional,
dad>Windows 2000 Server, Windows 2000 Advanced Server, or Windows 2000 Datacenter Server operating system
dad>Minimum of 32 megabytes (MB) of RAM. (64 MB or more is recommended. Additional memory may be required, depending on
dad>operating system requirements.)
dad>44 MB of available hard disk space
dad>---------------------------------------
dad>как Вам такой подарок?

Нормальные требования для более-менее приличной базы. Я его не юзал (поскольку уже давно перешел на MS SQL , но Микрософт утверждает, что он более производителен, чем Access и совместим по типам данных и языку запросов с MS SQL.

Здравствуйте Lexey, Вы писали:
L>Бред. В память считываются только нужные в данный момент части файла. Ты себе можешь представить считывание 2Gb-ного акцессного файла в память на машине с 128 метрами памяти?
гонт — шутил. не придавайте значения.
L>Вот XML в память грузится целиком, поскольку его парсить нужно.
там ниже(выше?) я конкретнее вопрос поставил

Здравствуйте dad, Вы писали:

dad>Здравствуйте Lexey, Вы писали:
L>>Бред. В память считываются только нужные в данный момент части файла. Ты себе можешь представить считывание 2Gb-ного акцессного файла в память на машине с 128 метрами памяти?
dad>гонт — шутил. не придавайте значения.
L>>Вот XML в память грузится целиком, поскольку его парсить нужно.
dad>там ниже(выше?) я конкретнее вопрос поставил

ИМХО, для больших объемов данных СУБД все же лучше.

Здравствуйте Lexey, Вы писали:

dad>>Здравствуйте Lexey, Вы писали:
L>>>Бред. В память считываются только нужные в данный момент части файла. Ты себе можешь представить считывание 2Gb-ного акцессного файла в память на машине с 128 метрами памяти?
dad>>гонт — шутил. не придавайте значения.
L>>>Вот XML в память грузится целиком, поскольку его парсить нужно.
dad>>там ниже(выше?) я конкретнее вопрос поставил

L>ИМХО, для больших объемов данных СУБД все же лучше.

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

Здравствуйте dad, Вы писали:

IT>>В любом случае, не помешает скачать с сайта MS последнюю версию MDAC http://www.microsoft.com/data/download.htm.

dad>спасибо, можно было и без стеба. Я имел ввиду бесплатность этих решений. Для редистрибьюции требуется приобрести к-ть программное обеспечение производства корпорации микрософт. А мне это совершенно не требуется. Как избежать таких ограничений?

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

Здравствуйте paul_shmakov, Вы писали:


PS> Мой Вам совет: даже и не думайте об этом! Да, xml сейчас очень популярен. Но он разработан не для хранения данных, а для унифицированного обмена данными между различными приложениями.

PS>Удачи!
Чисто человеческое спасибо, за столь развернутый совет. :)

Здравствуйте Lexey, Вы писали:

L>Вот XML в память грузится целиком, поскольку его парсить нужно.
Не факт, есть еще SAX парсеры, в этом случае файл в память целиком не закачивается...

Здравствуйте Merle, Вы писали:

M>Здравствуйте Lexey, Вы писали:

L>>Вот XML в память грузится целиком, поскольку его парсить нужно.
M>Не факт, есть еще SAX парсеры, в этом случае файл в память целиком не закачивается...

May be, SAX'ом ни разу не пользовался.

Здравствуйте Lexey, Вы писали:

L>Здравствуйте dad, Вы писали:

L>>>PS. А почему про MSDE ни слова? Он же тоже бесплатный и возможностей у него побольше, чем у Access.
dad>>по поводу МСДЕ — мне тут обратили внимание, на "подарок от микрософт", который хочет:
dad>>...
dad>>как Вам такой подарок?

L>Нормальные требования для более-менее приличной базы. Я его не юзал (поскольку уже давно перешел на MS SQL , но Микрософт утверждает, что он более производителен, чем Access и совместим по типам данных и языку запросов с MS SQL.

Если уж на то пошло, то MSDE — это MS SQL Server 7.0 с "заглушками". "Подарок" на самом деле очень и очень занимательный!

Здравствуйте dad, Вы писали:

dad>Как вы оцениваете вариант использования в качестве хранилища (БД) XML файло?
dad>Программа предполагается достаточно большой (я имею ввиду объем данных),
dad>но работа с данными не очень оперативная. Типичное учетно-аналитичекое приложение..
dad>---------
dad>плюсы:
dad>- наличие бесплатных парсеров
dad>соответсвенно низкая конечная стоимость и отсутсвие проблем с редистрибьюцией.

А почему бы не использовать н.п. MySQL/PHP :???:

Здравствуйте коллеги (извините, что вмешиваюсь)
Вы писали:

>>Здравствуйте paul_shmakov, Вы писали:
>>
>>PS>Здравствуйте dad, Вы писали:

>>dad>>Как вы оцениваете вариант использования в качестве хранилища (БД) XML файло?
>>dad>>Программа предполагается достаточно большой (я имею ввиду объем данных),
>>dad>>но работа с данными не очень оперативная. Типичное учетно-аналитичекое приложение..
>>
>>PS> Мой Вам совет: даже и не думайте об этом! Да, xml сейчас очень популярен. Но он разработан не для хранения >>данных, а для унифицированного обмена данными между различными приложениями.
>>
>>PS>Подумайте сами: xml — это всего навсего текстовый файл с большим количеством служебной информации. То, что >>существуют бесплатные xml-парсеры, всего лишь облегчает задачу чтения данных из этого файла. И не более. С таким же >>успехом можно было придумать свой формат, более эффективный, экономичный, и работать с ним своим набором функций.
>>
>>PS>Заметьте, разницы никакой! Но простой файл — это не база данных и уж тем более не СУБД. Вам придется написать кучу >>кода для доступа к этому файлу, сохранения изменений, обеспечения последовательного (хотя бы) одновременного доступа >>нескольких пользователей, аналог транзакций и т.д. — т.е. Вам придеться написать свою свою СУБД (!).
>>
>>PS>Зачем? Вы хотите унификации, простого переноса приложений, простую замену компонент?Так используйте технологии, >>которые позволят это сделать, например, в Вашем случае — OLE DB/ADO. И подключайте свое приложение сегодня к MS SQL, а >>завтра к бесплатному Interbase не меняя при этом ни строчки кода.
>>
>>PS>Ну а если так хочется применить для чего-нибудь XML, то предусмотрите экспорт/импорт данных в этом формате, храните >>настойки проложения в XML и т.п.
>>
>>PS>Удачи!

Мне представляется, что:
1. Использовать XML в качестве носителя данных можно, если
1.1. Хранящаяся информация в настоящий момент не имеет строго определенного формата (например — надо хранить характеристики игрушек, подъемных кранов, чего-нибудь еще (о чем сейчас не знаем)) — скорее учетное приложение
1.2. Не требуется полная статистика по всему !!! массиву данных.
1.3. Не существует больших !!! XML файлов, а много маленьких
2. В этом случае у Вас может быть база-реестр (реляционная скорее всего (MSDE — хороший вариант)) хранящихся документов и их основных характеристик (например стоимость, тип ...) с возможностью поиска нужных XML документов (содержащих полные спецификации). Выбранный документ будет обрабатываться клиентским приложением (к вопросу о ресурсах сервера).
3. Абсолютно согласен со всем, что сказал paul_shmakov (в особенности о популярности)
4. В дополнение, относительно импорта-экспорта. XML может быть хорошим вариантом при сборе информации (почти одинаковый код для получения данных по Internet, эл.почте, может сами, что-нибудь еще придумаете)
5. Написать свой собственный полноценный сервер гораздо дороже (за работу надо платить), чем купить готовый

С уважением Андрей
PS. Пока реляционные базы данных справляются с большей частью учетно-аналитических задач.
PPS. С удовольствием пообщался-бы с paul_shmakov (?) (мой адрес andrewbulat@hotmail.com)

dad>Как вы оцениваете вариант использования в качестве хранилища (БД) XML файло?

На больших объемах данных производительность XML неприемлима, нужно использовать механизмы БД. К тому же неочень понятно как в операциях с файлом будет поддерживаться одновременный доступ нескольких пользователей. Но ради списка из 100 позиций нет смысла строить новую таблицу, вполне можно ограничиться xml-файлом. Если он не будет часто менятся.

Здравствуйте The Lex, Вы писали:

TL>Здравствуйте Lexey, Вы писали:

L>>Здравствуйте dad, Вы писали:


L>>Нормальные требования для более-менее приличной базы. Я его не юзал (поскольку уже давно перешел на MS SQL , но Микрософт утверждает, что он более производителен, чем Access и совместим по типам данных и языку запросов с MS SQL.

TL>Если уж на то пошло, то MSDE — это MS SQL Server 7.0 с "заглушками". "Подарок" на самом деле очень и очень занимательный!

Не совсем в тему, но все же. Как подцепить базу к MSDE Вы случайно не в курсе?

Здравствуйте qbe451, Вы писали:

Q>Здравствуйте The Lex, Вы писали:

TL>>Здравствуйте Lexey, Вы писали:

L>>>Здравствуйте dad, Вы писали:


L>>>Нормальные требования для более-менее приличной базы. Я его не юзал (поскольку уже давно перешел на MS SQL , но Микрософт утверждает, что он более производителен, чем Access и совместим по типам данных и языку запросов с MS SQL.

TL>>Если уж на то пошло, то MSDE — это MS SQL Server 7.0 с "заглушками". "Подарок" на самом деле очень и очень занимательный!

Q>Не совсем в тему, но все же. Как подцепить базу к MSDE Вы случайно не в курсе?

В общем нет, не знаю, но MSDE — это точно MS SQL Server 7.0, управляется все тем же Enterprise Manager. Как подцепить файл БД и т.п. вопросы очень хорошо ставить на http://www.sql.ru — рекомендую!