Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 6 of 6 total |
Some DBISAM + ContextSoft ADO.NET Feedback |
Sun, Nov 25 2007 3:14 PM | Permanent 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 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 AM | Permanent Link |
Chris Holland SEC Solutions Ltd. 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 > > 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 AM | Permanent 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 >> >> 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 AM | Permanent Link |
Chris Holland SEC Solutions Ltd. 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 AM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 |
This web page was last updated on Thursday, March 28, 2024 at 06:05 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |