Hi,

We are just looking at speed optimisation for our recent web-based application (.NET) and was wondering whether typically the ADO.Net Provider offered by Context should provide better efficiency than the ODBC driver.  ODBC drivers are inherently quite slow from my experience.  We are currently using the ODBC driver.

Any experiences appreciated.  Also does anyone know whether Context provide a trial version to test whether there is any advantage in our scenario.

Thanks

Alex

Alex,

<<We are just looking at speed optimisation for our recent web-based
application (.NET) and was wondering whether typically the ADO.Net Provider
offered by Context should provide better efficiency than the ODBC driver.
ODBC drivers are inherently quite slow from my experience.  We are currently
using the ODBC driver. >>

The DBISAM ODBC Driver should be as-fast as a .NET data provider, in terms
of SQL performance and fetching.  ADO.NET uses a very basic design with
forward-only fetching, and this will be very fast with the native ODBC
driver and the ODBC.NET data provider that comes with VS.

Where exactly are you seeing performance issues ?  Is the ODBC driver
querying the data directly, or through a remote connection to a DBISAM
Database Server ?

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote:

<<Where exactly are you seeing performance issues ?  Is the ODBC driver
querying the data directly, or through a remote connection to a DBISAM
Database Server ?>>

Hi Tim,

Sorry for the delay in responding.  Our application is extremely slow. To give an example, it is taking 30 seconds or more for an edit screen to display, and then similar to save the entry (apparently it has to reprocess page creation on a save).  There are quite a number of SQL statements that are performed as part of the process but running the same SQL statements through a tool that allows you to use ODBC as the source, it takes under 3 seconds (on the web server).  We have been testing directly rather than through the database server but regardless I am stumped at the difference in time.  I have outsourced work on the speed of the web application and the programmer is adamant that the issue is with the database and ODBC connection but I am sceptical.  We do use DevExpress .NET components and I am not sure whether, for example, it's the drop-down population of a number of entry fields that is causing speed issues.

Thanks

Alex

Alex,

<< Sorry for the delay in responding.  Our application is extremely slow. To
give an example, it is taking 30 seconds or more for an edit screen to
display, and then similar to save the entry (apparently it has to reprocess
page creation on a save).  There are quite a number of SQL statements that
are performed as part of the process but running the same SQL statements
through a tool that allows you to use ODBC as the source, it takes under 3
seconds (on the web server). >>

If the actual ODBC execution is only 3 seconds with an external tool, then
it will also only be 3 seconds with .NET and the ODBC.NET data provider.
The only thing the data provider does is thunk out to the ODBC driver
manager and driver.  There is very little interpretation or translation
going on.

<< We have been testing directly rather than through the database server but
regardless I am stumped at the difference in time.  I have outsourced work
on the speed of the web application and the programmer is adamant that the
issue is with the database and ODBC connection but I am sceptical.  We do
use DevExpress .NET components and I am not sure whether, for example, it's
the drop-down population of a number of entry fields that is causing speed
issues. >>

I would consider using something like AQTime to profile the .NET code and
find out where the performance issues are.  It will be much easier to fix
once you know exactly where the problem is.

--
Tim Young
Elevate Software
www.elevatesoft.com