I am transitioning from DBISAM to Elevate. Most current versions.

In my DBISAM apps I basically only use the Query. This is because my databases are quite
relational, so "simple" table views rarely show useful data. With Elevate we have a "View"
construct, which allows the generation of canned views of multiple table data fields on
the server which users can open. This is a powerful tool, I would like to use it because I
assume it is much less intensive on the server and faster to open a View than a bespoke
piece of SQL with many joins.

First Question: Does anyone have experience of this & how much of an improvement is there??

I ask because it will be quite a bit of work to migrate to Views and I don't want to do it
if the improvement is small!

--

However, there is a further issue: I usually give my users a set of search options on
their Queries allowing them to pull different sub-sets of data (i.e. Customers with Orders
Outstanding, or Customers in London).

To do this with Views I need to apply a FILTER. This is not technically difficult BUT (a
second question!) Is it quicker to do:

1. Show View + Apply a filter to it.

or

2. Retrieve data with SQL Query?

And if I am doing 1., is there a mechanism for passing in the Filter at the start, so that
there is only 1 trip to the DB??

--

PS: I am childishly excited about EDB ... it seems really robust & fast in my initial trials!

Adam Brett

Adam,

<< In my DBISAM apps I basically only use the Query. This is because my
databases are quite relational, so "simple" table views rarely show useful
data. With Elevate we have a "View" construct, which allows the generation
of canned views of multiple table data fields on the server which users can
open. This is a powerful tool, I would like to use it because I assume it is
much less intensive on the server and faster to open a View than a bespoke
piece of SQL with many joins. >>

You won't see any difference between a view and a query in terms of the
first execution.  The benefit to views is that they can be opened multiple
times, and each subsequent open will use the cached execution of the query
that defines the view.

<< 1. Show View + Apply a filter to it.

or

2. Retrieve data with SQL Query? >>

There isn't a whole lot of difference, besides some extra calls to the
ElevateDB Server if you're using a remote session.

<< And if I am doing 1., is there a mechanism for passing in the Filter at
the start, so that there is only 1 trip to the DB?? >>

No, they would have to be executed as multiple steps/requests.

<< PS: I am childishly excited about EDB ... it seems really robust & fast
in my initial trials! >>

We test EDB pretty extensively using our test framework, so it is very
stable at this point in time.

--
Tim Young
Elevate Software
www.elevatesoft.com

>The benefit to views is that they can be opened multiple
>times, and each subsequent open will use the cached execution of the query
>that defines the view.

Great.

Also, my understanding is that this caching takes into account updates to the underlying
data, so that if 1 or 2 of the records change these changes are reflected without the
whole View having to rerun from scratch.

Is that correct?

Adam

Adam,

<< Also, my understanding is that this caching takes into account updates to
the underlying data, so that if 1 or 2 of the records change these changes
are reflected without the whole View having to rerun from scratch. >>

No, if the underlying data changes, then the whole view will need to be
re-executed.  In this respect, it operates just like a query.  However, the
refresh operation itself does nothing unless the underlying data changes.

--
Tim Young
Elevate Software
www.elevatesoft.com