Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 6 of 6 total
Thread Some DBISAM + ContextSoft ADO.NET Feedback
Sun, Nov 25 2007 3:14 PMPermanent Link

"Hedley Muscroft"
Hi Tim/Eryk et al,

Crumbs... it's been a long while since I posted on this newsgroup. About a
year ago I migrated away from Delphi to C#, which unfortunately meant
changing my 'backend of choice' away from DBISAM.

I wanted to choose a 100% managed .NET solution for my embedded database,
and after much research I went for VistaDB (www.vistadb.net). It looked
incredibly promising, boasts some excellent features (for an embedded
database) and has a good team behind it (including Mike Orlov formerly from
ApolloDB).

Unfortunately, after months of grappling with VistaDB 3, the performance is
still absolutely dreadful and despite being a supposedly 'finished' product
it is still very buggy.

I coded a small C# (.NET 2) test app to compare the three databases I've
been working with, namely :-
[1] VistaDB 3 (latest 'stable' build 43)
[2] DBISAM (4.25b7) using ContextSoft's DBISAM ADO.NET Provider (v2.20).
[3] PGSQL (8.25) using CoreLabs PGSQL ADO.NET Provider (v 3.25)

This is by NO means a comprehensive benchmark (I was, afterall, selfishly
trying to work out what worked best for my application), but the results
were interesting and I wanted to share - plus this may provide some positive
feedback for anyone thinking of using DBISAM with ADO.NET.

I tested 3 SELECT statements (with between 3-5 joins) which I use *very*
often in my app and averaged up the results. All the SELECTs return about
1500 records on the test database I was using. Here are the average speed
results based on 3 different scenarios :-

On my local computer (with the database on my local hard disk) :-
[1] VistaDB - avg 5.2 secs
[2] DBISAM - avg 0.8 secs
[3] PGSQL - avg 0.3 secs

Accessing the database across my LAN (100Mbit)
[1] VistaDB - avg 61 (yes 61) secs
[2] DBISAM - avg 5 secs
[3] PGSQL - avg 0.8 secs

Accessing the database wirelessly (56Mbit encrypted)
[1] VistaDB - avg 120 secs
[2] DBISAM - avg 11 secs
[3] PGSQL - avg 1.8 secs

[I should point out that in order to use DBISAM with ContextSoft's ADO.NET
drivers, you have to use the C/S Engine. In fact, I ran the DBISAM server
LOCALLY on each computer, and told the DBISAM Server to server a folder over
the network. This was intentional, because the figures I were really
interested in were "DBISAM vs VistaDB" in file-based mode. Running the
DBISAM server on the host machine results in a further slight performance
boost, though not as good as PGSQL]

Bottom line? As a result of this, I have completely ditched VistaDB (and am
considering asking for a refund) and returned to DBISAM with ContextSoft's
ADO.NET drivers Smile

One question : I would like to use VIEWs and CONTSTRAINTS (which VistaDB
does support) and I note they are present in ElevateDB, but I downloaded the
ElevateDB trial and couldn't find any native ADO.NET 2 drivers. Have they
been released yet, or are they on the way?

Anyway, I hope some of this information is useful, or at least marginally
interesting!

Kind Regards,

Hedley Muscroft
Pioneer Software Ltd [http://www.pioneersoftware.co.uk]

Mon, Nov 26 2007 2:36 AMPermanent Link

Chris Holland

SEC Solutions Ltd.

Avatar

Team Elevate Team Elevate

Hi Hedley,

The ADO driver for ElevateDB is nearly ready, Tim has said he is just
finishing it up in other posts in this newsgroup.

There is an ODBC driver available for the ElevateDB (and DBISAM) that I
have been using with Visual Studio, .NET and C# with no problems.

Also if you buy the ODBC driver for ElevateDB you get the ADO driver
when it is released.

Chris Holland


Hedley Muscroft wrote:
> Hi Tim/Eryk et al,
>
> Crumbs... it's been a long while since I posted on this newsgroup. About a
> year ago I migrated away from Delphi to C#, which unfortunately meant
> changing my 'backend of choice' away from DBISAM.
>
> I wanted to choose a 100% managed .NET solution for my embedded database,
> and after much research I went for VistaDB (www.vistadb.net). It looked
> incredibly promising, boasts some excellent features (for an embedded
> database) and has a good team behind it (including Mike Orlov formerly from
> ApolloDB).
>
> Unfortunately, after months of grappling with VistaDB 3, the performance is
> still absolutely dreadful and despite being a supposedly 'finished' product
> it is still very buggy.
>
> I coded a small C# (.NET 2) test app to compare the three databases I've
> been working with, namely :-
> [1] VistaDB 3 (latest 'stable' build 43)
> [2] DBISAM (4.25b7) using ContextSoft's DBISAM ADO.NET Provider (v2.20).
> [3] PGSQL (8.25) using CoreLabs PGSQL ADO.NET Provider (v 3.25)
>
> This is by NO means a comprehensive benchmark (I was, afterall, selfishly
> trying to work out what worked best for my application), but the results
> were interesting and I wanted to share - plus this may provide some positive
> feedback for anyone thinking of using DBISAM with ADO.NET.
>
> I tested 3 SELECT statements (with between 3-5 joins) which I use *very*
> often in my app and averaged up the results. All the SELECTs return about
> 1500 records on the test database I was using. Here are the average speed
> results based on 3 different scenarios :-
>
> On my local computer (with the database on my local hard disk) :-
> [1] VistaDB - avg 5.2 secs
> [2] DBISAM - avg 0.8 secs
> [3] PGSQL - avg 0.3 secs
>
> Accessing the database across my LAN (100Mbit)
> [1] VistaDB - avg 61 (yes 61) secs
> [2] DBISAM - avg 5 secs
> [3] PGSQL - avg 0.8 secs
>
> Accessing the database wirelessly (56Mbit encrypted)
> [1] VistaDB - avg 120 secs
> [2] DBISAM - avg 11 secs
> [3] PGSQL - avg 1.8 secs
>
> [I should point out that in order to use DBISAM with ContextSoft's ADO.NET
> drivers, you have to use the C/S Engine. In fact, I ran the DBISAM server
> LOCALLY on each computer, and told the DBISAM Server to server a folder over
> the network. This was intentional, because the figures I were really
> interested in were "DBISAM vs VistaDB" in file-based mode. Running the
> DBISAM server on the host machine results in a further slight performance
> boost, though not as good as PGSQL]
>
> Bottom line? As a result of this, I have completely ditched VistaDB (and am
> considering asking for a refund) and returned to DBISAM with ContextSoft's
> ADO.NET drivers Smile
>
> One question : I would like to use VIEWs and CONTSTRAINTS (which VistaDB
> does support) and I note they are present in ElevateDB, but I downloaded the
> ElevateDB trial and couldn't find any native ADO.NET 2 drivers. Have they
> been released yet, or are they on the way?
>
> Anyway, I hope some of this information is useful, or at least marginally
> interesting!
>
> Kind Regards,
>
> Hedley Muscroft
> Pioneer Software Ltd [http://www.pioneersoftware.co.uk]
>
>
Mon, Nov 26 2007 5:38 AMPermanent Link

"Hedley Muscroft"
Thanks for the update Chris,

I think I'll hold fire for a couple of months until the EDB ADO provider
matures a little. I'm on a tight deadline and have wasted so much time with
VistaDB, that I need something that's going to be robust. Hopefully DBISAM +
ContextSoft will be the answer.

That said, I will be keeping a close eye on EDB once the ADO provider is
ready. Did you migrate from DBISAM -> EDB and if so what was your experience
performance-wise/hassle-wise?


"Chris Holland" <mail@chrisholland.me.uk> wrote in message
news:DF4AAB15-6915-4444-B44B-B71D1E7D2190@news.elevatesoft.com...
> Hi Hedley,
>
> The ADO driver for ElevateDB is nearly ready, Tim has said he is just
> finishing it up in other posts in this newsgroup.
>
> There is an ODBC driver available for the ElevateDB (and DBISAM) that I
> have been using with Visual Studio, .NET and C# with no problems.
>
> Also if you buy the ODBC driver for ElevateDB you get the ADO driver when
> it is released.
>
> Chris Holland
>
>
> Hedley Muscroft wrote:
>> Hi Tim/Eryk et al,
>>
>> Crumbs... it's been a long while since I posted on this newsgroup. About
>> a year ago I migrated away from Delphi to C#, which unfortunately meant
>> changing my 'backend of choice' away from DBISAM.
>>
>> I wanted to choose a 100% managed .NET solution for my embedded database,
>> and after much research I went for VistaDB (www.vistadb.net). It looked
>> incredibly promising, boasts some excellent features (for an embedded
>> database) and has a good team behind it (including Mike Orlov formerly
>> from ApolloDB).
>>
>> Unfortunately, after months of grappling with VistaDB 3, the performance
>> is still absolutely dreadful and despite being a supposedly 'finished'
>> product it is still very buggy.
>>
>> I coded a small C# (.NET 2) test app to compare the three databases I've
>> been working with, namely :-
>> [1] VistaDB 3 (latest 'stable' build 43)
>> [2] DBISAM (4.25b7) using ContextSoft's DBISAM ADO.NET Provider (v2.20).
>> [3] PGSQL (8.25) using CoreLabs PGSQL ADO.NET Provider (v 3.25)
>>
>> This is by NO means a comprehensive benchmark (I was, afterall, selfishly
>> trying to work out what worked best for my application), but the results
>> were interesting and I wanted to share - plus this may provide some
>> positive feedback for anyone thinking of using DBISAM with ADO.NET.
>>
>> I tested 3 SELECT statements (with between 3-5 joins) which I use *very*
>> often in my app and averaged up the results. All the SELECTs return about
>> 1500 records on the test database I was using. Here are the average speed
>> results based on 3 different scenarios :-
>>
>> On my local computer (with the database on my local hard disk) :-
>> [1] VistaDB - avg 5.2 secs
>> [2] DBISAM - avg 0.8 secs
>> [3] PGSQL - avg 0.3 secs
>>
>> Accessing the database across my LAN (100Mbit)
>> [1] VistaDB - avg 61 (yes 61) secs
>> [2] DBISAM - avg 5 secs
>> [3] PGSQL - avg 0.8 secs
>>
>> Accessing the database wirelessly (56Mbit encrypted)
>> [1] VistaDB - avg 120 secs
>> [2] DBISAM - avg 11 secs
>> [3] PGSQL - avg 1.8 secs
>>
>> [I should point out that in order to use DBISAM with ContextSoft's
>> ADO.NET drivers, you have to use the C/S Engine. In fact, I ran the
>> DBISAM server LOCALLY on each computer, and told the DBISAM Server to
>> server a folder over the network. This was intentional, because the
>> figures I were really interested in were "DBISAM vs VistaDB" in
>> file-based mode. Running the DBISAM server on the host machine results in
>> a further slight performance boost, though not as good as PGSQL]
>>
>> Bottom line? As a result of this, I have completely ditched VistaDB (and
>> am considering asking for a refund) and returned to DBISAM with
>> ContextSoft's ADO.NET drivers Smile
>>
>> One question : I would like to use VIEWs and CONTSTRAINTS (which VistaDB
>> does support) and I note they are present in ElevateDB, but I downloaded
>> the ElevateDB trial and couldn't find any native ADO.NET 2 drivers. Have
>> they been released yet, or are they on the way?
>>
>> Anyway, I hope some of this information is useful, or at least marginally
>> interesting!
>>
>> Kind Regards,
>>
>> Hedley Muscroft
>> Pioneer Software Ltd [http://www.pioneersoftware.co.uk]

Mon, Nov 26 2007 7:53 AMPermanent Link

Chris Holland

SEC Solutions Ltd.

Avatar

Team Elevate Team Elevate

I did a conversion from DBISAM 4 to ElevateDB 1.06 using the existing
ODBC drivers.

The connection string changes were very minimal and took only a couple
of minutes.

I had to rewrite quite a bit of my SQL, mostly converting string tests
from "UPPER()" to use the new "COLLATE ANSI_CI"

Also all of the table creates had to be re-written, but the ElevateDB
manager reverse engineers the SQL code for you.

I cant say with the brief tests that I performed that I noticed any
speed differences between DBISAM and ElevateDB.

The most time consuming part of the conversion was not the coding but
getting my head around the way the new configuration files and catalogs
worked.

Chris Holland

> That said, I will be keeping a close eye on EDB once the ADO provider is
> ready. Did you migrate from DBISAM -> EDB and if so what was your experience
> performance-wise/hassle-wise?
Mon, Nov 26 2007 8:26 AMPermanent Link

"Hedley Muscroft"
Thanks for the excellent information Chris - no doubt I'll be posting more
questions when I come to doing the same! Thanks again.

"Chris Holland" <mail@chrisholland.me.uk> wrote in message
news:DF07F242-7436-413B-A34F-D6AC09493C38@news.elevatesoft.com...
>I did a conversion from DBISAM 4 to ElevateDB 1.06 using the existing ODBC
>drivers.
>
> The connection string changes were very minimal and took only a couple of
> minutes.
>
> I had to rewrite quite a bit of my SQL, mostly converting string tests
> from "UPPER()" to use the new "COLLATE ANSI_CI"
>
> Also all of the table creates had to be re-written, but the ElevateDB
> manager reverse engineers the SQL code for you.
>
> I cant say with the brief tests that I performed that I noticed any speed
> differences between DBISAM and ElevateDB.
>
> The most time consuming part of the conversion was not the coding but
> getting my head around the way the new configuration files and catalogs
> worked.
>
> Chris Holland
>
>> That said, I will be keeping a close eye on EDB once the ADO provider is
>> ready. Did you migrate from DBISAM -> EDB and if so what was your
>> experience performance-wise/hassle-wise?

Mon, Nov 26 2007 5:05 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Hedley,

<< I think I'll hold fire for a couple of months until the EDB ADO provider
matures a little. I'm on a tight deadline and have wasted so much time with
VistaDB, that I need something that's going to be robust. >>

The .NET data providers are pretty brain-dead simple, and the EDB .NET data
provider shares most of its connection code with the already-working ODBC
driver.  The trickiest issues are the design-time environment extensions and
installation.  I don't think you'll have any issues with the EDB .NET data
provider when it is released, which right now is targeted for Wednesday.
The VS.NET 2003 provider is done, and the VS2005 provider is almost there
also.  I did both in order to get myself more "acquainted" with the .NET
data environment and its progression from VS2003 onward.  However, initially
the .NET data providers will not have design-time extensions and will not,
like the VCL.NET releases for BDS2006 and RAD Studio 2007, have external
managed code module support for procedures, functions, text filters, word
generators, and migrators, which is still in development.

--
Tim Young
Elevate Software
www.elevatesoft.com

Image