Hedley,

<< Yes, I now understand how EDB handles VIEWs. Please forgive my ignorance
in this matter Tim. >>

BTW, I didn't mean for that to sound snotty, so my apologies if that's the
way it came across.  I was writing "conversationally", and sometimes it's
hard to ask a question like that without it looking odd when read.

<< Do you mean "this is how they work in EDB"? >>

Yes, of course.

<< Although I don't have anywhere near your experience, with other engines
I've used (PGSQL, MySQL, SQL Server), I have never noticed that using a VIEW
+ WHERE clause has come with any kind of performance hit like EDB does. >>

It's always possible.  Each database engine is designed differently.  EDB is
designed to implement views like tables, so that they are opened once and
stay open until they are closed.  This means that as long as they are
opened, they will not need to be executed again and will materialize
immediately.  You'll see this with greater effect once we allow you to do
something similar to the KeepTablesOpen setting.

<< I am curious as to when you would recommend the use of VIEWs in EDB? (The
only time I can think of is if you're executing the exact same SELECT SQL
over-and-over and if you hold on to the prepared VIEW query?) >>

See my above paragraph.

<< Would that help the scenario when you're JOINing a query to one or more
VIEWs? (I do that quite a lot and it's still a bit slow). >>

Only in the same sense as any other query that references views, i.e. the
JOINs don't play any part in the equation.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thanks for the info Tim.

>> BTW, I didn't mean for that to sound snotty, so my apologies
>> if that's the way it came across.
No problem! I'm sure I speak for everyone in this newsgroup in saying that
we really appreciate your help & support, and even if you did get a little
snotty at times, we wouldn't blame you!

>> EDB is designed to implement views like tables,
>> so that they are opened once and stay open until
>> they are closed.  This means that as long as they
>> are opened, they will not need to be executed again
>> and will materialize immediately.  You'll see this with
>> greater effect once we allow you to do something similar
>> to the KeepTablesOpen setting.

Hmmm... I see how that will work in Delphi, but ADO.NET is designed around
'disconnected' datasets i.e. open connection - get data - close connection /
open connection - write date - close connection.

How do we keep a VIEW (or a TABLE for that matter) open in ADO.NET?

Hedley,

<< Hmmm... I see how that will work in Delphi, but ADO.NET is designed
around 'disconnected' datasets i.e. open connection - get data - close
connection / open connection - write date - close connection. >>

Yes, and we already discussed this - you're going to have to keep the
connection open if you want decent performance with the EDB Data Provider.
That is the only requirement for the KeepTablesOpen attribute/property to do
its job.

--
Tim Young
Elevate Software
www.elevatesoft.com

OK - thanks.