"Sam Davis" <sammyd432@yahoo.com> wrote in message
news:D78B06DD-5F0C-453A-A225-495E6A8C1811@news.elevatesoft.com...
> David Farrell-Garcia wrote:
>
>>>Why? Depends on the situation, and represents a lot of work and
>>>losing a lot of the features found in tTable.
>>
>>
>> Does this really need a explaination?

Yes. If you are in business, you need to explain why you would want to
invest xxxx dollars in changing ttables to tqueries. Which is the issue
here. If you code from scratch to use C/S, it might be a differente story
(even there, one has to look at each individual situation). I can give you a
number of examploes in which a ttable is much better than a tquery.

You don't understand the
>> advantage of using SQL to query data on a server vs opening a
>> DbiasamTable?

What I don't agree with is the idea that one size fits all. Or with the
advice to "change all tables to queries", as if that were a trivial matter
in a large applications.

Robert

Sam Davis wrote:
> But won't a TDBISAMTable when using client
> server, filter the data on the server? Like it does with ranges?

Yes, but it is really just as eassy to write SQL as it is to code the
filter and more flexible. In addition your app becomes more portable if
the backend should ever change.  It is just good practice.  I can,
however, fully understand a reluctance to change an existing
TDbisamTable base app if the costs are too high for the benefit.


--
David Farrell-Garcia
Whidbey Island Software, LLC

Robert wrote:

> What I don't agree with is the idea that one size fits all. Or with
> the advice to "change all tables to queries", as if that were a
> trivial matter in a large applications.

I do agree that the cost to benefit would have to be evaluated in each
case, especially cwhen converting existing appliacations. It is simply
better (more portable) design for "most" business apps to use SQL
rather then table filters/ranges to fetch data. I often use
ClientDataSets client side, which greatly simplifies things client
side, giving you the advantages of working with DbisamTables while
still using still using SQL.


--
David Farrell-Garcia
Whidbey Island Software, LLC

David Farrell-Garcia wrote:

> Robert wrote:
>
>
>>What I don't agree with is the idea that one size fits all. Or with
>>the advice to "change all tables to queries", as if that were a
>>trivial matter in a large applications.
>
>
> I do agree that the cost to benefit would have to be evaluated in each
> case, especially cwhen converting existing appliacations. It is simply
> better (more portable) design for "most" business apps to use SQL
> rather then table filters/ranges to fetch data. I often use
> ClientDataSets client side, which greatly simplifies things client
> side, giving you the advantages of working with DbisamTables while
> still using still using SQL.
>
>

I still use a Table is when I need the ultimate speed and a Range will
work. The problem with SQL of course it needs to parse the SQL command,
fetch the rows, create a temporary table (static query), and physially
sort it. I've found a Where clause with a Sort is usually faster for
Static queries than for Live queries. But this results in a heck of a
lot more CPU and disk activity than a Table with a Range.

Sam

Sam Davis wrote:

> I still use a Table is when I need the ultimate speed and a Range
> will work. The problem with SQL of course it needs to parse the SQL
> command, fetch the rows, create a temporary table (static query), and
> physially sort it.

I believe that when using a Table the request is converted to SQL
before fetching the data from the Dbisam Server. How else would it
work? It seems to me that would be an extra step. But in any case, my
reasons for sticking to SQL, rather then a table, are not for
performance but because of portability of the code which enables me to
more easily abrstract the database logic from the user Interface or
controller.


<I've found a Where clause with a Sort is usually
> faster for Static queries than for Live queries. But this results in
> a heck of a lot more CPU and disk activity than a Table with a Range.

I believe it is the canned Query that results in the extra activity on
the client as it must make a a copy of the table.  Anyway,I have found
using DbisamQuery/sql to be quite fast for our application, even over
remote connections.

--
David Farrell-Garcia
Whidbey Island Software, LLC

Sam,

<< Sure SQL is the way to go. But won't a TDBISAMTable when using client
server, filter the data on the server? Like it does with ranges? Or does it
still pull the data down to the client to do the filtering? >>

Both DBISAM and EDB perform filters and ranges on the server.

--
Tim Young
Elevate Software
www.elevatesoft.com

David,

<< Does this really need a explaination?  You don't understand the advantage
of using SQL to query data on a server vs opening a DbiasamTable?  You might
get by with that in an app that never generates much data but other then
that it woudl be foolish. >>

Opening a table grabs no more data than opening a live query result set, and
live queries are basically just tables with filters set.  There are actually
a lot of similarities between the two.  The real benefit of SQL is with
large joined or aggregated queries that process a lot of data, which would
simply be unacceptable to try using navigational methods.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:
> Opening a table grabs no more data than opening a live query result
> set, and live queries are basically just tables with filters set.
> There are actually a lot of similarities between the two.  The real
> benefit of SQL is with large joined or aggregated queries that
> process a lot of data, which would simply be unacceptable to try
> using navigational methods.

Well, I guess I never gave DbisamTables a chance.  Typically, using
TTables in a C/S application was considered bad practice and I suppose
I carried that thinking over to Dbisam. I still prefer using SQL, for a
number of reasons.  Is there any performance benefit to using
DbisamTables for other then "large jointed or aggregated queries"?


--
David Farrell-Garcia
Whidbey Island Software, LLC

David,

<< Well, I guess I never gave DbisamTables a chance.  Typically, using
TTables in a C/S application was considered bad practice and I suppose I
carried that thinking over to Dbisam. I still prefer using SQL, for a number
of reasons.  Is there any performance benefit to using DbisamTables for
other then "large jointed or aggregated  queries"? >>

Very minor.  Basically you eliminate the SQL parsing/compilation, but that's
about it.  However, you may need to use a TEDBTable in EDB in order to
simply open a view.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> David,
>
> << Well, I guess I never gave DbisamTables a chance.  Typically, using
> TTables in a C/S application was considered bad practice and I suppose I
> carried that thinking over to Dbisam. I still prefer using SQL, for a number
> of reasons.  Is there any performance benefit to using DbisamTables for
> other then "large jointed or aggregated  queries"? >>
>
> Very minor.  Basically you eliminate the SQL parsing/compilation, but that's
> about it.  However, you may need to use a TEDBTable in EDB in order to
> simply open a view.
>

David,
    Unfortunately SQL encryption is not secure (as it should be). IMHO,
tables are much better.

Sam