SQLite. Хотя мне и не нравится ее типизация.

Также можно посмотреть в сторону Firebird Embedded.

авторчто б приложение можно на флешке перенести и развернуть на любой машине, при этом интерфейс планируется реализовать на .NET.
OFFTOPIC: Если нужно действительно НА ЛЮБОЙ МАШИНЕ, то советую выбросить нафиг .NET, а использовать кроссплатформенный Java. Ибо венда ваша - не единственная ОС в мире. Есть еще Маки, линуксы и другие unix-like OS. Жаба есть везде, а ваш дотнет - только на вашей недовенде.

servit Mono (Cross Platform)
Об этом знаю. Сам под него писал.

НО: Mono - не .NET. Да, моно - отличная платформа для кроссплатформенной разработки, и т.д. и т.п., но это - совсем другая платформа, а не клон дотнета.

Если программа консольная, и не завязана на какие-либо особенности венды (да хотя бы пути к папкам и файлам), и не использует unmanaged библиотеки и не является mixed assembly, то да - проблем обычно нет. Она будет одинаково хорошо работать и в Mono, и в .NET.

Если программа имеет GUI, то здесь появляются проблемы (хоть и преодолимые, но все же). Дело в том, что Windows.Forms, который практически всегда используется дотнетчиками, не является родным для Mac OS X или Linux. Да, он реализован (частично) для этих платформ, но работает медленно и выглядит плохо (просто реализация Windows.Forms не является приоритетной задачей Mono), а также в большинстве дистрибутивов Linux Windows.Forms (а также сопутствующие ему) выделен в отдельный пакет, который большинство пользователей никогда не устанавливает (потому, что нужен он только тем, кому нужно запускать приложения, написанные под винду под его .NET). Для создания GUI на Linux и других Unix-like обычно применяют Gtk# - обертку для Gtk. Gtk# (как и сам Gtk и Mono) существует и под винду, но в случае топикстартера решение с Gtk# никак не соответствует его требованиям. Чтобы запустить приложение для Gtk#, нужно иметь этот самый Gtk# и Gtk. А чтобы это запускалось на любом компьютере, нужно этот самый Gtk и Gtk# положить вместе с самой программой, а весят они не так уж мало.

Еще несколько проблем, которые мешают использовать Mono для запуска .NET приложений:
1. Не поддерживаются mixed-assembly (потому, что mono - не эмулятор винды и не будет исполнять нативный виндовый код) (я когда-то ради одной программы, которая не имеет аналогов, и которая представляет собой этот самый mixed assembly, ставил мелкомягкий .NET 2.0 в wine :) )
2. Синтаксис C# Mono не на 100% идентичный C# от MS (там отличий очень мало, но я как-то сталкивался) (это только если вы собираетесь компилировать ваш код компилятором от MS).
3. Mono не поддерживает Linq.
4. Куча несоответствий между поведением .NET и Mono.

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

Можно, конечно, пытаться разработать программу, которая будет работать как под .NET, так и под Mono, но тогда придется как минимум отказаться от Windows.Forms и использовать что-то кроссплатформенное (хотя бы тот же Gtk#).

Dimitry Sibiryakovfrp1. Не поддерживаются mixed-assembly (потому, что mono - не эмулятор винды и не будет
исполнять нативный виндовый код)

А выполнять нативный линуховый или маковский код им не позволяет что?

Спросите у разработчиков. Подозреваю, что либо из соображений безопасности, либо из соображений переносимости. Потому, что от включения mixed assembly и то, и другое пострадает.

Vinny the POOHfrp(оченьмногабукаф)



Поэтому можно взять Qt - и не иметь проблем ни с переносимостью, ни с кроссплатформенностью, ни с реализацией.
Я не спорю, но с тем способом, которым автор хочет переносить программу, а также если учесть, что автор экономит в размере даже на СУБД, то Qt ему, скорее всего, плохо подойдет (программу на Qt нужно компилировать под все нужные платформы, и сама Qt много весит (автор ведь не станет надеяться, что Qt чудесным образом оказался у пользователя в system32 :) ). Я сам использую Qt по возможности. А Java есть практически везде, меньше весит, байт-код кроссплатформенный.

Dimitry SibiryakovVinny the POOHПоэтому можно взять Qt - и не иметь проблем ни с переносимостью, ни с
кроссплатформенностью, ни с реализацией.

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


Сколько видел программ, использующих Qt, и ни одна не запрещала изменять ширину колонки грида с помощью мыши - простым драг-н-дропом. По дефолту такое изменение ширины разрешено (по крайней мере в Qt 3 и Qt 4, с более ранними не знаком). Странные вы программы видели.

PS. Тормоза на ровном месте были только в ранних версиях Qt 4. Начиная с Qt 4.5 никаких тормозов не замечал.

Dmitry ArefievПрименительно к Qt и БД - а как там вообще с БД работать ? Не ... там конечно
же есть соответствующие классы, но стандартная реализация, например, для
Firebird не выдерживает никакой критики. Другие драйвера особо не изучал, но
на поверхности не увидел многого и для других СУБД. Честно скажу - лишь читал
исходники, запускал демки, больше - дела не имел. Потому интересно - как
люди работают ?
Dmitry Arefievно стандартная реализация, например, для Firebird не выдерживает никакой критики.
Вообще, интерфейс для общения с базой базонезависим, то есть Firebird или не Firebird, важно только на этапе подключения к базе, дальнейшая работа для разных баз практически не отличается.
Интерфейс этот, кстати, довольно удобен в использовании и отлично документирован. А исходники демок читать бесполезно, там нет ничего интересного, лучше сами попробуйте пописать под него, а потом уж обсуждайте этот интерфейс.

И почему это реализация для Firebird не выдерживает никакой критики? (сам пользовался только SQLite и MySQL)