I'm designing a new application that will have UI screens that need to gather data from 5
to 10 tables, present the data to the user, allow them to edit it, and then apply the
changes back to the underlying database.

I want to stay away from table controls. I am looking at using TXxxQuery controls to
gather the data, and data aware controls to present the data to the user.

I've not done any extensive work with SQL and TXxxQuery controls in the past, so I've been
reading through a lot of newsgroup posts trying to see how others handle this. If I
understand things correctly, DBSIAM and EDB, do not apply changes made to a query result
set back to the underlying database tables if joins are involved (which will be the case
for most of what I'm doing).      
         
What are the best practices for doing this type of thing?
                                                  
Is there anything in EDB to handle this that is not in DBISAM?

I read about the TEDBUpdateSQL and TDBISAMUpdateSQL, and these look like they could be
useful for what I’m talking about, but the manual says they require the use of
TClientDataSet components. I've never used client datasets, and I did not find any
examples in DBISAM, EDB, or in the newsgroups so I'm not sure what is involved. Is this a
popular approach, and something I should consider, or is this an obsolete technique?

Several people are using middleware frameworks like kbmMW and RemObjects DataAbstract. In
looking at these products, it appears that they allow complex datasets to be defined that
join data from several tables, and then have capabilities to apply these changes back to
the underlying datasets. Much of what I read seems like things I'm trying to do. But I'm
not sure if they are overkill for what I'm doing.

In a few of the newsgroup messages I read, I though Tim mentioned that future versions of
EDB may enhance the support for live dataset. I thought I read that maybe in the future
views and queries with joins may have capabilities to resolve changes back to the
underlying database tables, or support live updates to the underlying table(s). I tried
going back and finding the places where I read these things, but I can't seem to locate
themthem. So, maybe this really isn't something that is planned. Does anyone know?

Sorry in advance if these are basic questions, but this is a new area for me. What I'm
basically trying to do is to come up with a good, sound technique for retrieving sets of
data (from multiple, but related tables), allow the user to edit the data, and then to
apply the changes back to the database. The application will probably have 40 to 50 UI
screens where this needs to be done.

So, before I start to hand code all the database update code, I thought I'd post a message
here to see how others do it. I appreciate any input on this.
     
Thanks,

-Kevin

Kevin,

<< Is there anything in EDB to handle this that is not in DBISAM? >>

No.

<< I read about the TEDBUpdateSQL and TDBISAMUpdateSQL, and these look like
they could be useful for what I’m talking about, but the manual says they
require the use of TClientDataSet components. I've never used client
datasets, and I did not find any examples in DBISAM, EDB, or in the
newsgroups so I'm not sure what is involved. Is this a popular approach, and
something I should consider, or is this an obsolete technique? >>

Using the TClientDataSet is a valid approach to this issue, and still widely
used.   The other technique used is to simply use something like this:

CREATE TEMPORARY TABLE ResultTable AS SELECT .......  WITH DATA

with a TEDBQuery component.   Then open the ResultTable table with a
TEDBTable component and use the AfterPost event handler for the TEDBTable
component to populate any changes back into their respective tables.

<< In a few of the newsgroup messages I read, I though Tim mentioned that
future versions of EDB may enhance the support for live dataset. I thought I
read that maybe in the future views and queries with joins may have
capabilities to resolve changes back to the underlying database tables, or
support live updates to the underlying table(s). I tried going back and
finding the places where I read these things, but I can't seem to locate
themthem. So, maybe this really isn't something that is planned. Does anyone
know? >>

Yes, this is planned.  Internally, views can have triggers defined against
them, and we plan to use the trigger layer to support INSTEAD OF triggers
that allow you to distribute changes to a non-updateable view back to the
respective tables that make up the view.

<< Sorry in advance if these are basic questions, but this is a new area for
me. What I'm basically trying to do is to come up with a good, sound
technique for retrieving sets of data (from multiple, but related tables),
allow the user to edit the data, and then to apply the changes back to the
database. The application will probably have 40 to 50 UI
screens where this needs to be done. >>

Well, in most cases you simply cannot get around the fact that you'll have
to hand-code the resolution SQL or code that handles resolving the query
updates back to the respective tables.  Especially if you don't intend to
include all of the primary key values from the respective tables and instead
use another table's values to find the appropriate row to update.

--
Tim Young
Elevate Software
www.elevatesoft.com