Subject | Re: [firebird-support] Question regarding Embeded version of FB |
---|---|
Author | Svein Erling Tysvaer |
Post date | 2007-03-30T10:14:59Z |
Hi, since no-one else has answered you:
The multi-generational architecture is the core of Firebird and it is
very different from MS Access (Firebird is more comparable to SQL
Server). Even though the embedded version doesn't support multi-user
access, it doesn't throw away this core aspect of Firebird (someone
please correct me if I'm wrong).
I think you could expect retrieving up to about 10000 rows per second
with Firebird, or rather, this was the maximum I heard of a few years
ago so it is likely to have improved a bit with Firebird 2.0.
Some of the main benefits compared to a desktop database like MS Access,
are the multiuser access and the consept of transactions (also, I would
expect that Firebird less often gets corrupted, but I don't know MS
Access well enough to tell with any certainty). This leads to thinking
in terms of datasets rather than tables, which can be a huge benefit.
If MS Access serves your requirements and the main reason for
considering a change is that you want a speed increase in single user
processing, then (excepting that thinking in datasets rather than tables
can help you improve your code) I'd be slightly surprised if Firebird
was your answer.
Rather, I would expect something similar to kbmMemTable to be
appropriate for you, but that is for Delphi and I have no idea what is
available with VB.
Out of curiosity, what kind of application are you developing?
Set
bzm72 wrote:
The multi-generational architecture is the core of Firebird and it is
very different from MS Access (Firebird is more comparable to SQL
Server). Even though the embedded version doesn't support multi-user
access, it doesn't throw away this core aspect of Firebird (someone
please correct me if I'm wrong).
I think you could expect retrieving up to about 10000 rows per second
with Firebird, or rather, this was the maximum I heard of a few years
ago so it is likely to have improved a bit with Firebird 2.0.
Some of the main benefits compared to a desktop database like MS Access,
are the multiuser access and the consept of transactions (also, I would
expect that Firebird less often gets corrupted, but I don't know MS
Access well enough to tell with any certainty). This leads to thinking
in terms of datasets rather than tables, which can be a huge benefit.
If MS Access serves your requirements and the main reason for
considering a change is that you want a speed increase in single user
processing, then (excepting that thinking in datasets rather than tables
can help you improve your code) I'd be slightly surprised if Firebird
was your answer.
Rather, I would expect something similar to kbmMemTable to be
appropriate for you, but that is for Delphi and I have no idea what is
available with VB.
Out of curiosity, what kind of application are you developing?
Set
bzm72 wrote:
> Hi,
>
> I have a VB6 application that uses MS Access as BE database through ADO.
> It is a single-user application.
>
> It;s a highly intensive data processing app, and I need its processing
> speed to increase. I don't need multi-users shared access.
>
> I just found the firebird db and saw it has an embeded version. Is it
> possible with this version to make my app use database and do all
> processing in memory (without flushing to disk)? Well, I will want
> floshing to disk only after the whole processing, since there asre no
> concurent users who need to get access to database.
>
> I guess this could increase the speed of the app.
>
> Also, how fast is firebird , compared with MS Access?
>
> I thought of firebird because I saw it has OleDB provider, so I can use
> it with ADO and this will involve only minor changes in my app (maybe
> slightly adjustments to queries, since the whole processing, incliding
> running queries, retriaving recordsets , etc will remain unchanged
>
> Also, if you could give me some suggestions how to maximally optimnize
> speed, by giving up at multi-user, and wioth help of embeded engine, I'l
> highly appreciate.
>
> Thank you
>
> Bogdan Zamfir