Search found 8 matches
- Thu 22 Sep 2011 06:19
- Forum: Universal Data Access Components
- Topic: New UniDAC version 4.0 is available for download now.
- Replies: 8
- Views: 1507
- Thu 30 Jun 2011 12:00
- Forum: Universal Data Access Components
- Topic: static resultset
- Replies: 3
- Views: 1234
- Thu 30 Jun 2011 11:01
- Forum: Universal Data Access Components
- Topic: static resultset
- Replies: 3
- Views: 1234
static resultset
I sometimes need a static resultset, which means: the server table is queried and subsequent sql operations don't affect that resultset.
In ADO I used Cursortype ctStatic but in Unidac I can't find something like that.
I have to process very large table sizes and if there is a way to do that without copying to a local VirtualTable it would be helpfull. The resultset is ReadOnly and UniDirectional.
In ADO I used Cursortype ctStatic but in Unidac I can't find something like that.
I have to process very large table sizes and if there is a way to do that without copying to a local VirtualTable it would be helpfull. The resultset is ReadOnly and UniDirectional.
- Fri 20 May 2011 08:24
- Forum: SQL Server Data Access Components
- Topic: Feature request:TMSQuery.GenerateParametrizedSQL
- Replies: 24
- Views: 4831
Hello AndreyZ,
I think this is the right way to prioritize the user requests.
But I have to ask another question: I've seen that slow queries with parameters on my previous version which was ADO-based and changed many queries to simple sql-text without parameters (therefore this feature request has not the highest priority for me). If that is a ADO/OLEDB-problem, possibly it's better to make a SpecificOption for MSSQLprovider, which you can faster implement and test?
What is your experience (as devart) in your other products (.Net, DBExpress): Are there parameters on SQLServer-queries also bad?
If not: Can there go something wrong in the implementation of the parameters for the MSSQLProvider?
I think this is the right way to prioritize the user requests.
But I have to ask another question: I've seen that slow queries with parameters on my previous version which was ADO-based and changed many queries to simple sql-text without parameters (therefore this feature request has not the highest priority for me). If that is a ADO/OLEDB-problem, possibly it's better to make a SpecificOption for MSSQLprovider, which you can faster implement and test?
What is your experience (as devart) in your other products (.Net, DBExpress): Are there parameters on SQLServer-queries also bad?
If not: Can there go something wrong in the implementation of the parameters for the MSSQLProvider?
- Wed 18 May 2011 06:30
- Forum: SQL Server Data Access Components
- Topic: Feature request:TMSQuery.GenerateParametrizedSQL
- Replies: 24
- Views: 4831
Can you review http://devart.uservoice.com/forums/1046 ... ?ref=title , if this is what you want and add a vote?
As seen in other feature request's: more votes -> higher priority for implementing!
As seen in other feature request's: more votes -> higher priority for implementing!
- Tue 03 May 2011 12:38
- Forum: Universal Data Access Components
- Topic: Static linking of sqlite dll
- Replies: 2
- Views: 1092
You can vote for my UserVoice-Entry. Possibly they add it.
- Thu 10 Feb 2011 08:25
- Forum: Universal Data Access Components
- Topic: Cancel CachedUpdates
- Replies: 1
- Views: 1111
Cancel CachedUpdates
A TUniQuery has ApplyUpdates and CancelUpdates.
A TUniConnection has ApplyUpdates and documentation says, it's then "preferred method of updating datasets rather than calling each individual dataset's ApplyUpdates method".
Why is there no equivalent CancelUpdates for TUniConnection?
A TUniConnection has ApplyUpdates and documentation says, it's then "preferred method of updating datasets rather than calling each individual dataset's ApplyUpdates method".
Why is there no equivalent CancelUpdates for TUniConnection?
- Wed 09 Feb 2011 16:01
- Forum: Universal Data Access Components
- Topic: VirtualTable and UpdateSql
- Replies: 2
- Views: 1286
VirtualTable and UpdateSql
I'd like to populate a memory-table with data from a complicated query. After that I need the user-changes from this memory-table written to the DB-Server. My first try was a TVirtualTable (perfect for populating) connected to a TUniUpdateSql (perfect for Updating). But that is not possible.
Is there a other way to mirror changes in a TVirtualTable to Sql-Statements?
Can I populate a TUniQuery manually and only use CachedUpdates for userchanges after that point?
Andreas
Is there a other way to mirror changes in a TVirtualTable to Sql-Statements?
Can I populate a TUniQuery manually and only use CachedUpdates for userchanges after that point?
Andreas