Board index » delphi » First access to any table is very slow

First access to any table is very slow

This may be a BDE question, i'm not sure.  But I have an interbase database
and a Delphi display.  Upon running the application, the first time that I do
something (access a dbcombobox, post a new record, edit an existing record), a
tremendous delay results.  This only occurs the first time I access something
and subsequent accesses are much faster.  What is causing this first-access
delay?

--
Ron Denis
Consultant
Lucent Technologies Inc.

 

Re:First access to any table is very slow


Delphi apps don't automatically load the BDE at startup. When you do
something that needs the BDE (i.e. access a dbcombobox, etc.) it loads the
BDE, which takes a while. To avoid this, pre-load the BDE when starting
your app by doing some database access operation.
--
Brian Fabian Go

My reply e-mail is false to avoid bulk e-mailers.
My true e-mail is brian...@skyinet.net.

http://www.skyinet.net/users/brianfgo/

Ron Denis <oe...@exchange.wcc.lucent.com> wrote in article
<uwwrwybqe....@exchange.wcc.lucent.com>...

Quote
> This may be a BDE question, i'm not sure.  But I have an interbase
database
> and a Delphi display.  Upon running the application, the first time that
I do
> something (access a dbcombobox, post a new record, edit an existing
record), a
> tremendous delay results.  This only occurs the first time I access
something
> and subsequent accesses are much faster.  What is causing this
first-access
> delay?

Re:First access to any table is very slow


Quote
Ron Denis <oe...@exchange.wcc.lucent.com> wrote:
>This may be a BDE question, i'm not sure.  But I have an interbase database
>and a Delphi display.  Upon running the application, the first time that I do
>something (access a dbcombobox, post a new record, edit an existing record), a
>tremendous delay results.  This only occurs the first time I access something
>and subsequent accesses are much faster.  What is causing this first-access
>delay?

I noticed this too.  I don't know the technical answer, but I'm sure
that it has something to do with DLLS loading.  The best way around
this I found was to do a datbase call when your program starts.  Users
expect a delay at this point, so it's the perfect opportunity to
"initialize" that code.

Hope this helps,
-Ed
gi...@clark.net

Quote
>--
>Ron Denis
>Consultant
>Lucent Technologies Inc.

Re:First access to any table is very slow


This 'problem' may come from the fact that the BDE must query the DB to get
table information before working with the table the first time.  Once it
has the information, it is able to cache it and will work quickly
throughout the remainder of the session (while TDatabase.Connection remains
True).  To use the cached information between runs, goto the BDE config
program to the particular alias you are using to connect through and set
BDE CACHE = TRUE and BDE CACHE DIR = 'C:\temp' or wherever you want the
files to be stored.

NOTE: Be aware that if you change your table definition, you will need to
delete the file in this Cache dir that represents it.  You can find the
filename in the SCache.INI file located in the same directory by viewing it
in your favorite text editor.

Hope this helps.

L8r,

-jimo

+----------------------------------------------------------------+
 \ My motto: 'Being happy through living, learning, and loving.'  \
  \ Quote: 'Being wise is an effective use of intelligence in      \
   \           being happy.' -Brigetta Barone & Jim OFlaherty, Jr. \
    \                                                                \
     \ Jim O'Flaherty, Jr.        j...@sequel.com        817-577-4114 \
      \                          Hurst, Texas, USA                     \
       +----------------------------------------------------------------+

Ron Denis <oe...@exchange.wcc.lucent.com> wrote in article
<uwwrwybqe....@exchange.wcc.lucent.com>...

Quote
> This may be a BDE question, i'm not sure.  But I have an interbase
database
> and a Delphi display.  Upon running the application, the first time that
I do
> something (access a dbcombobox, post a new record, edit an existing
record), a
> tremendous delay results.  This only occurs the first time I access
something
> and subsequent accesses are much faster.  What is causing this
first-access
> delay?

> --
> Ron Denis
> Consultant
> Lucent Technologies Inc.

Re:First access to any table is very slow


Quote
Ron Denis wrote:

> This may be a BDE question, i'm not sure.  But I have an interbase database
> and a Delphi display.  Upon running the application, the first time that I do
> something (access a dbcombobox, post a new record, edit an existing record), a
> tremendous delay results.  This only occurs the first time I access something
> and subsequent accesses are much faster.  What is causing this first-access
> delay?

> --
> Ron Denis
> Consultant
> Lucent Technologies Inc.

The quick answer is "Versioning". Interbase makes a 'copy' of the data
you are looking at when you begin an edit.  It exists in Server RAM, and
is saved when you commit, or when a sweep occurs.

--
-----------------------------------------
Software Services - Making Windows Scream
http://www.invsn.com/softserv/
bry...@thevision.net
-----------------------------------------

Re:First access to any table is very slow


Quote
Bryan Valencia wrote:

> Ron Denis wrote:

> > This may be a BDE question, i'm not sure.  But I have an interbase database
> > and a Delphi display.  Upon running the application, the first time that I do
> > something (access a dbcombobox, post a new record, edit an existing record), a
> > tremendous delay results.  This only occurs the first time I access something
> > and subsequent accesses are much faster.  What is causing this first-access
> > delay?

> The quick answer is "Versioning". Interbase makes a 'copy' of the data
> you are looking at when you begin an edit.  It exists in Server RAM, and
> is saved when you commit, or when a sweep occurs.

On a similar vein, I believe the BDE, upon first access to a table,
sucks down informaion about the schema (how many fields, which are
indexed, which have NOT NULL requirements, blah, blah, blah...).
This information is "cached" so that subsequent table accesses do not
suffer  the performance hit of downloading this information again.

While I use Oracle, not Interbase, this effect is similar to the
one you describe...

--
-------------------------------------------------------
"I never gave anybody Hell.  I just told them the truth
 and they thought it was Hell..."   -Harry S. Truman

Other Threads