🚀 go-pugleaf

On Mon, 15 Feb 1999 12:01:31 -0500, Richard Muzerolle wrote:

> I have created the following query:

Most queries constructed with other than a very simple select
statement will be read-only.  You are better off using a dataModule to
create this arrangement of tables and link them using the
MasterRowset/Masterfields properties.


Gary

Some dBASE Stuff at
http://www.AppTools.com/dbase

On Mon, 15 Feb 1999 12:01:31 -0500, "Richard Muzerolle" <muzzy@muznet.net>
wrote:

[...]

>My first problem is that I can not edit the table created??

This is true. All multi-table join result sets will be read-only. It is up
to the application front-end to accommodate such read-only result sets and
provide a means for updating the data in the separate base tables.
Different front-end software packages handle this differently. Gary pointed
out how you might go about handling this in Visual dBASE. In C++Builder and
Delphi, it is handled different from that (using cached updates). And in
other software packages still differently.

>My second problem is that only one of the hyd_flow.FLOW_AVAIL shows up when
>I need all three in the three last lines to show??

Can you elaborate on exactly what you meant by the above? In your original
SQL statement, the column hyd_flow.FLOW_AVAIL appeared only one time. So I
do not understand what you meant by not showing three times.

Did you mean in three records the hyd_flow.FLOW_AVAIL column was blank
(when you expected a non-NULL value)? Could this be a result of the query's
OUTER JOIN and non-matching records?

//////////////////////////////////////////////////////////////////////////
Steve Koterski                       "For people who like peace and quiet:
Technical Publications               a phoneless cord."
INPRISE Corporation                                             -- Unknown
http://www.inprise.com/delphi

In article <36cc3350.1357578@forums.inprise.com>, Steve Koterski politely 
paraphrased ...
> 
> This is true. All multi-table join result sets will be read-only. It is up
> to the application front-end to accommodate such read-only result sets and
> provide a means for updating the data in the separate base tables.
> Different front-end software packages handle this differently. Gary pointed
> out how you might go about handling this in Visual dBASE. In C++Builder and
> Delphi, it is handled different from that (using cached updates).
---
Also with normal DBFs? AFAIK the only way the big guys doing it is by 
sending SQL code to the server which then need a way to uniquely identify 
the concerned row(s) which can only be done if all the tables have a 
primary key, no?

-- 
Romain Strieff [TeamB]
Please read this newsgroup guide below before 
posting on the private Inprise newsgroups.
http://www.inprise.com/newsgroups/guide.html
--

On Thu, 18 Feb 1999 12:28:53 +0100, teamb@opto-pps.com (Romain Strieff
[TeamB]) wrote:

>In article <36cc3350.1357578@forums.inprise.com>, Steve Koterski politely 
>paraphrased ...
>> 
>> This is true. All multi-table join result sets will be read-only. It is up
>> to the application front-end to accommodate such read-only result sets and
>> provide a means for updating the data in the separate base tables.
>> Different front-end software packages handle this differently. Gary pointed
>> out how you might go about handling this in Visual dBASE. In C++Builder and
>> Delphi, it is handled different from that (using cached updates).
>---
>Also with normal DBFs? AFAIK the only way the big guys doing it is by 
>sending SQL code to the server which then need a way to uniquely identify 
>the concerned row(s) which can only be done if all the tables have a 
>primary key, no?

The existence of a primary key might uniquely identify a row in a base
table, but does not itself make an association between a rows in a result
set and that row in the base table. When columns from multiple base tables
are combined to produce a single result set (i.e., a join), the result set
is essentially the same as a table, only it is virtual. The columns in the
result set belong to the result set, not to a base table. Thus the result
set itself cannot be editable.

In Delphi, with cached updates such a result is made to appear editable.
But it is not really. It is just smoke and mirrors. The data-aware controls
make it look like the result set is being edited but the changes are really
going into a separate, cached dataset. Once all data modifications (new
rows added, existing rows edited, and rows deleted) have been made, these
cached changes are applied. That is, each cached change record is evaluated
and an SQL statement executed to take the change for any one cached record
and update the appropriate base table (UPDATE, INSERT, or DELETE). The
trick is that the SQL statement must correctly identify the right base
table, something done manually in composing the individual update SQL
statements.

Delphi and to some extent Visual dBASE are more low-level in treating this.
No presuppositions are made about how the programmer wants the base tables
updated. That must be handled manually and explicitly; the programmer must
specify how and in what tables any changes will be made. For this reason,
multi-table queries are read-only, but the means for handling that manually
provided as a side dish. A more high-level environment (Microsoft Access?)
might just do this handling for you, applying the changes in a manner that
seems most logical -- most logical to whoever programmed the environment
software. But even there, the multi-table query is still read-only. It is
just that the software automates the processes to make the result set
appear updatable and that apply changes.

//////////////////////////////////////////////////////////////////////////
Steve Koterski                       "For people who like peace and quiet:
Technical Publications               a phoneless cord."
INPRISE Corporation                                             -- Unknown
http://www.inprise.com/delphi

In article <36d7bdd3.11272288@forums.inprise.com>, Steve Koterski 
politely paraphrased ...
> 
> The existence of a primary key might uniquely identify a row in a base
> table, but does not itself make an association between a rows in a result
> set and that row in the base table. When columns from multiple base tables
> are combined to produce a single result set (i.e., a join), the result set
> is essentially the same as a table, only it is virtual. The columns in the
> result set belong to the result set, not to a base table. Thus the result
> set itself cannot be editable.
---
Even not with Interbase or Oracle? 

> In Delphi, with cached updates such a result is made to appear editable.
> But it is not really. It is just smoke and mirrors. The data-aware controls
> make it look like the result set is being edited but the changes are really
> going into a separate, cached dataset. Once all data modifications (new
> rows added, existing rows edited, and rows deleted) have been made, these
> cached changes are applied. That is, each cached change record is evaluated
> and an SQL statement executed to take the change for any one cached record
> and update the appropriate base table (UPDATE, INSERT, or DELETE). The
> trick is that the SQL statement must correctly identify the right base
> table, something done manually in composing the individual update SQL
> statements.
---
I understood the SQL servers did it the same way. 
 

-- 
Romain Strieff [TeamB]
Please read this newsgroup guide below before 
posting on the private Inprise newsgroups.
http://www.inprise.com/newsgroups/guide.html
--

In article <7a9jpu$5604@forums.borland.com>, muzzy@muznet.net says...
> My second problem is that only one of the hyd_flow.FLOW_AVAIL shows up when
> I need all three in the three last lines to show??
> 
> 

I see the last two lines as reaching the 2048 byte count for the string. 
(a quick scan gives me 2047 to the end of the second line)   I'm always 
suspicious when a failure occurs at a nice easy number like this.<g>

For a quick test, try dropping a few non-critical fields from the select 
string, it should tell you if the byte count (command line length) is 
significant.  If it works I would map that long hard coded path to a nice 
easy logical drive letter, and save about 30 bytes/file reference.  Even 
better, create a BDE alias and avoid the problems of hard coding a path 
within your code.

-- 
pf