DELPHI to Access performance

DELPHI to Access performance

Post by David L » Tue, 26 Sep 1995 04:00:00



Grateful for some comments on lack of performance of DELPHI link to
Access using ODBC.  A developer I have talked to claim lack of speed
of such links (compared to VB) caused him to drop the idea of using
DELPHI.  He has lots of vested interests in continuing with the use of
Access and switching to Paradox/Interbase is not on for his retail
clients.  Personally I concur with him Access is an important tool
because of availability, security features, extent of existing
knowledge and functionality (e.g. endusers can get good additional
reports to supplement supplied functions by using Access tools).

I also like the performance, language aspects of DELPHI and would like
to see it work well with Access.

Thanks in advance for comments and insights.

 
 
 

DELPHI to Access performance

Post by Steve Koters » Tue, 26 Sep 1995 04:00:00



>Grateful for some comments on lack of performance of DELPHI link to
>Access using ODBC.  A developer I have talked to claim lack of speed
>of such links (compared to VB) caused him to drop the idea of using
>DELPHI.  He has lots of vested interests in continuing with the use of
>Access and switching to Paradox/Interbase is not on for his retail
>clients.  Personally I concur with him Access is an important tool
>because of availability, security features, extent of existing
>knowledge and functionality (e.g. endusers can get good additional
>reports to supplement supplied functions by using Access tools).
>I also like the performance, language aspects of DELPHI and would like
>to see it work well with Access.

Table access to the same table type through a native driver and through
ODBC will result (nearly always) in slower access in the ODBC method than
that for the native driver. How much slower will depend on a number of
circumstances, including the efficiency of the ODBC driver.

Native support for MS Access tables is not possible through Delphi using
the default data engine -- the Borland Database Engine (BDE) -- only
through ODBC (which does also pass through the BDE layer). Microsoft has
not released the Access database specification for licensed use in
third-party applications and database packages.

An alternative data engine from a third-party (the Rocket engine from
SuccessWare is one example) may not provide direct access to Access
databases, but may provide a faster utilization of the ODBC access.

**************************************************************************
Steve Koterski
Local InterBase Server Technical Support
Borland International, Inc.

 
 
 

DELPHI to Access performance

Post by Rune Mobe » Sat, 30 Sep 1995 04:00:00




> Access using ODBC.  A developer I have talked to claim lack of speed
> of such links (compared to VB) caused him to drop the idea of using
> DELPHI.  He has lots of vested interests in continuing with the use of
> Access and switching to Paradox/Interbase is not on for his retail

Well, if he had switched, he'd notice that Paradox has
 - better record locking (doesn't lock an entire 2K page)
 - less corruption. If one table is totally destroyed (like restoring a
   backup of open MDB files), you can still salvage the other tables.
 - more speed (at least when I compared VB/Access to Delphi/Paradox).

Quote:> clients.  Personally I concur with him Access is an important tool
> because of availability, security features, extent of existing

Security?

If I remember correctly, it's enough to delete system.mda or just copy
the .mdb file (provided no-one else is using it) to another location?

Anyway, a disk editor should take care of that. Want protection?
Think SQL server. Think Delphi C/S.

Quote:> I also like the performance, language aspects of DELPHI and would like
> to see it work well with Access.

Until MS loosens up, and either provide a bugfree ODBC driver or necessary
documentation of the JET engine, that is not going to happen. This is a
MS problem, not Borland. But hey, it's your time they're wasting, not mine!
;-)

=\
 *=- R.Moberg, author of CD-Player Pro! ftp.cica.indiana.edu:
=/                                      /win3/sounds/cdppro45.zip

 
 
 

DELPHI to Access performance

Post by Anders Ekela » Sun, 01 Oct 1995 04:00:00


But the real problem for Borland is that a lot of people have Access
as part of their MS-Office. When users have got used to MS-Access,
developed reports etc. They are not going to convert to Paradox just
because it is better in some respects.

That in practice means that a lot of developpers will be stuck with VB
4.0 - wich of course is inferior to Delphi - but still will do the job
- some way or another.

This means that Delphi will not be the industri standard Development
Tool. Borland will suffer, developers will suffer, users will suffer
from this.

That is why solving the slowness of reading the MS-Acces tables must
be a top priority for Borland. Strike a deal with the Devil (MS) -
build opinion for MS to release the Jet Engine API etc.

Anders E

 
 
 

DELPHI to Access performance

Post by Robert Sma » Tue, 03 Oct 1995 04:00:00



>But the real problem for Borland is that a lot of people have Access
>as part of their MS-Office. When users have got used to MS-Access,
>developed reports etc. They are not going to convert to Paradox just
>because it is better in some respects.

[other stuff snipped]

I agree completely.

My company (or at least the company I work for) have standardised on
MS-Office. There are now many apps using Access.

I would like to use Delphi (as an alternative to VB3) for some
projects, BUT, it must work with the existing Acess databases.
==
Bob Small

 
 
 

DELPHI to Access performance

Post by Richard Vowl » Thu, 05 Oct 1995 04:00:00


: That is why solving the slowness of reading the MS-Acces tables must
: be a top priority for Borland. Strike a deal with the Devil (MS) -
: build opinion for MS to release the Jet Engine API etc.

I don't see this as being likely - MS won't even give you a table
of the damned error messages, you have to ring them up for each one!

I agree, it would be most worthwhile to have a faster Access interface
and I understand from someone elses comments that the 32-bit ODBC
does provide considerably faster access than previous ODBC's (which
was Microsoft's standard as was so brain damaged that it was almost
unusable). Perhaps someone could verify this...?

--
"...I'll leave my mind beneath the mat, so you can let yourself in,
if you can stand the mess then stay, but i'm not entertaining..."

 
 
 

DELPHI to Access performance

Post by Sundial Servic » Fri, 06 Oct 1995 04:00:00




>: That is why solving the slowness of reading the MS-Acces tables must
>: be a top priority for Borland. Strike a deal with the Devil (MS) -
>: build opinion for MS to release the Jet Engine API etc.
>I don't see this as being likely - MS won't even give you a table
>of the damned error messages, you have to ring them up for each one!
>I agree, it would be most worthwhile to have a faster Access interface
>and I understand from someone elses comments that the 32-bit ODBC
>does provide considerably faster access than previous ODBC's (which
>was Microsoft's standard as was so brain damaged that it was almost
>unusable). Perhaps someone could verify this...?

I think that MS is going to provide only an ODBC-style interface to their
product because then they can change the internals as necessary with only a
change to the driver.  If third-parties are unable to create products that use
those internal calls directly, then no one will be calling MS Tech Support
with questions and complaints shortly after a new release comes out.  (Well...)

My experience is that Access-to-Delphi performance is acceptable, and
interestingly, much better than PxWin-to-Access; but only if you have the
current drivers from Microsoft.  I don't know what PxWin's problem is but
Delphi works quite nicely.  Granted it is slightly slower than Access itself
on the database side, but Delphi provides enough of a highly-visible speed
improvement on the user-interface side that the program, in the end, runs much
faster for the users.

To complete this mildly-dissenting opinion, then, let me say that when I am
building an application like this one, I'll personally sacrifice a small
amount of speed if it relieves me of the fear that the next release of Access
is going to deep-six my applications or force me to provide an interim version
or to support two versions.

/mr/

 
 
 

DELPHI to Access performance

Post by Michael Bar » Sat, 07 Oct 1995 04:00:00


I agree with most of this thread. Borland does need to make
support for MS Access a priority, but in a controlled way.

There are some other advantages to using the Delphi/Paradox database engine
over MS's Access/Jet besides speed and the development power of Delphi.
The primary one that we see at our company is data security & integrity.

We still have a large number of dBase/Clipper apps being used, and we have
found that some "self-proclaimed" power users have found that they can open
DBF files with "end-user" tools, like Excel. When a user starts playing
"what-if" and report games with a database file that is at the heart
of a system that requires data & referential integrity, thousands of hours
of both program development and program use can be thrown out the window.

If we develop new systems with tools like MS Access/VB then we stand a
good chance of having this happen. My stance has been that we use Delphi,
but provide an export component that generates Access files that the user
can build reports and play other games with.

I don't want to discourage a user from being creative or inquisitive, but rather
give them a strong foundation to play on. If you can articulate that to some
of your power users, I think you can advance the cause for having Delphi
as the tool of choice for developing the key infrastructure of your
information systems.

Just my opinions.
MB

 
 
 

DELPHI to Access performance

Post by Ebbe Jonss » Tue, 10 Oct 1995 04:00:00


: I don't see this as being likely - MS won't even give you a table
: of the damned error messages, you have to ring them up for each one!

Last time I looked, http://www.microsoft.com/Support/KBSL/deskapps/acces/
Q114856.htm contained a 'Complete Reserved Error List for Microsoft
Acces 2.0'.

--


Fax: +358 0 33 88 22                                    " Why me? "

 
 
 

1. Performance delphi 4 & Access through ODBC

Hello,

I'm working on a Delphi 4 datalogging application which I would like to log
to an MS Access database. I've made a connection to a table in an existing
Access database and it works fine, but it's too slow. I must be able to log
2 times per second, and this works fine for the first 100 records or so but
after that, the creation of a record starts too take longer and longer.

It is correct that the time it takes to create a record in an Access table
from Delphi through ODBC depends on the size of the table? And what can I do
to overcome this?

Your help would be appreciated very much, thanx.

Jan.

2. foxweb

3. Slow performance Access 97/Delphi 4

4. Ingres/HP-UX Screen handling problem

5. TechTips: Improving Performance in Paradox/Delphi, or, Beating MS-Access at its Own Game

6. US-RI-ORACLE PORTAL DEVELOPER NEEDED IN PROVIDENCE, RHODE ISLAND

7. can delphi client/server 16bit be accessed by delphi 2/3

8. Delphi...Delphi....Delphi - New Delphi Site

9. Accessing MS Access under Linux with Delphi 6?

10. Accessing MS-Access with delphi

11. Accessing a MS Access Database with Delphi 4