In Marketing terms, these are very different databases. MSDE is
basically a selling ploy for MS-SQL. If you develop your application
against MSDE, when a larger customer comes along, the natural upgrade
path is to MS-SQL. The MSDE limitations are not architectual (at least
at these sizes). They are programatic limitations that force it to be
"not good enough" where they can possibly sell some MS-SQL licences.

There are a number of factors here.

1. Small projects generally can not afford database license costs.
2. Developers are the main goal. If a developer will not choose your
paid for option, then you would rather them use something else of
yours so they have a familiarity with your paid-for tools should they
ever be in the position of deciding which RDBMS to use for a project.
3. The limitations may look a long way off when starting a project.
You will be told that there will never be more than a couple of
simultaneous users, and may not anticipate the volume of data you will
be eventually required to maintain.
4. For developers used to MS-SQL who are moving onto a smaller
project, it keeps the eyes off other potential options like Firebird /
Postgres / and to some extent Interbase and MySQL.

Inevitably, MSDE feeds customers into MS-SQL.

Firebird does not have a income generating big brother to feed.
Limitations are not put there just so you can sell your paid for
version. The 1024 limit may well increase in the future as servers
become more powerful, resources cheaper, and internal representations
increased. The maximum database size really depends on what the file
system can support, as well as other internal implementation limits,
such as rows per table, tables per database etc. Again, these limits
are not in place to get you to buy something else, but rather are a
consequence of particular design decisions, and will probably increase
in subsequent versions. This is already true for index sizes, which in
FB 2 can take 1/4 of the page size of the database instead of <
250something bytes.

Furthermore, with Firebird, you get the source, which you are free to
make your own build that increases these limits. I would suggest that
if it was as easy as changing a constant, it would already be done,
but it offers some comfort.

So I believe it is a no-brainer. Providing Firebird is capable for
what you need, and you are prepared to invest a bit of learning in
transaction management and MGA, you would have to be a bit short
sighted IMO to start a new project using a commercially limited
product like MSDE.

Adam




--- In firebird-support@yahoogroups.com, "William Gonzáles S."
<wgonzaless@y...> wrote:

>
> Hi, thank you so much for the answers.
> I put the question about concurrent and non-concurrent
> users, because I am migrating a DB from MSDE to FB,
> the limitations of MSDE:
> 1) Only 5 concurrent users ("acting at the same
> time").
> 2) Up to 25 non-concurrent users (up to 25
> connections).
> 3) Max DB size: 2 GB
>
> Is FB better in this aspect?
>
> William GS.
>
>
>
> --- Alan McDonald <alan@m...> wrote:
>
> > > > -----Original Message-----
> > interesting take on non-concurrent....
> > not sure it's a valid question actually - or rather
> > I'm not sure he's asking
> > the right question for the answer he really wants.
> >
> > concurrent - "acting at the same time"
> > how many users can firebird have when they do not
> > act on the database at the
> > same time.
> > seems to me to be as many as will fit in the unique
> > constraints fo the
> > security database, or the max record number of the
> > users table whichever is
> > the lowest.
> > Alan
> >
> >
> >
>
>
>
>
>
> __________________________________
> Yahoo! Mail - PC Magazine Editors' Choice 2005
> http://mail.yahoo.com
>