Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 3 of 3 total
Thread Read Only Datasets
Mon, Oct 27 2014 8:46 PMPermanent Link

Fred Schetterer

Let me see if I have this correct.
If my query returns a NON sensitive result I have no way of updating it unless I copy all the data to memory or temp tables?

As per: http://www.elevatesoft.com/forums?action=view&category=edb&id=edb_general&page=1&msg=15791#15791
even UpdateSQL is not an option without copying all the data to a TClientDataset which then requires MidasLib?

On a networked db a second connection query time already increases a passable 3 seconds to 18 seconds and now I am supposed to copy this data again...

..am I missing something?
Mon, Oct 27 2014 10:10 PMPermanent Link

Raul

Team Elevate Team Elevate

On 10/27/2014 8:46 PM, Fred Schetterer wrote:
> If my query returns a NON sensitive result I have no way of updating it unless I copy all the data to memory or temp tables?

Yes - you cannot update the query result set that is not sensitive.

You can still run update sql statements (insert/update/delete) and they
will update the underlying data (just not live-update the result set you
already have). These can be wrapped in a transaction if you wish to
batch them and apply once.

> On a networked db a second connection query time already increases a passable 3 seconds to 18 seconds and now I am supposed to copy this data again...
> .am I missing something?

Without knowing what you need to achoeve its hard to suggest anything
but generally you don't want to bring multiple copies of data back.
Either see if you can turn it into a sensitive set or otherwise just
send the updates back.

Raul
Mon, Oct 27 2014 10:28 PMPermanent Link

Fred Schetterer

What I want is the ability to use UpdateSQL, something I have used since D3 or 4.
For that to work the Dataset must be editable yet not self updating.

Borland on that from the D6 help file:
TUpdateSQL provides a mechanism for circumventing what some developers consider an SQL-92 limitation. It enables a developer to provide INSERT, UPDATE, and DELETE statements for performing separate update queries on otherwise read-only result sets in such a manner that the separate update queries are transparent to the end user.

In practical application, a TUpdateSQL object is placed on a data module or form, and linked to a TQuery or TStoredProc component through that component’s UpdateObject property. If the UpdateObject property points to a valid TUpdateSQL object, the SQL statements belonging to the update object are automatically applied when cached updates are applied
Image