Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 3 of 3 total |
Read Only Datasets |
Mon, Oct 27 2014 8:46 PM | Permanent 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 PM | Permanent Link |
Raul 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 PM | Permanent 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 |
This web page was last updated on Tuesday, April 30, 2024 at 03:55 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |