Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 9 of 9 total |
.NET Data Provider and 1.07 Release Status |
Fri, Dec 7 2007 4:02 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Just a quick note to let everyone know that I'm working as fast as I can
right now on wrapping up the .NET data provider and the upcoming 1.07 release. It shouldn't be more than a few more days, but it will simply be ready "when it's ready". The VS2005 design-time integration is coming along, but is fairly substantial and is the main thing holding up things at this point. 1.07 includes new functionality in the form of a SELECT statement RANGE clause for applying ranges to result sets to limit which rows appear in the result set. This is required for the .NET provider to allow for pagination, and is also very nice for the VCL products in order to restrict the work required to populate a result set. If used with parameters instead of constant values, you can modify the range without requiring the query to be re-prepared. Furthermore, if you increase the end value of the range incrementally via parameters, ElevateDB will simply continue from where it left off in terms of populating the result set. For example, if you start out with: SELECT * FROM MyTable RANGE 1 TO 10 ElevateDB will only populate 10 rows into the result set. If you then use: SELECT * FROM MyTable RANGE 100 TO 110 ElevateDB will populate the rows from 11 through 110. This means that if you use: SELECT * FROM MyTable RANGE 20 TO 30 the rows will already have been generated, thus requiring no more work on the part of ElevateDB. One caveat, however, is that using the RANGE clause automatically results in an insensitive result set. Also, this clause doesn't limit the amount of work that ElevateDB has to do for aggregate or ordered queries that must generate the entire result set before selecting ranges. Please don't ask me about specific variations on ORDER BY clauses in terms of existing indexes - initially the rules are exactly as stated and EDB doesn't optimize for specific situations where an index might exist for the ORDER BY. Finally, the MaxRowCount property will be gone as of 1.07 due to the new RANGE functionality. Having both is just simply too confusing for developers and it is best if only the RANGE functionality exists for limiting rows. -- Tim Young Elevate Software www.elevatesoft.com |
Sat, Dec 8 2007 5:31 AM | Permanent Link |
"Harry de Boer" | Tim,
Is a solution there already in 1.07 that solves the problem of the (dis)connect thread in the NG where you stated: >>Actually, hold tight for the next build and I think I can get something in there. Apparently they snuck a new API call in Windows 2000 and higher called SetThreadExecutionState that will allow me to prevent shutdown when the pinging thread is running.<< Regards, Harry "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> schreef in bericht news:F4C9D994-F387-4A31-9790-F975544F73E7@news.elevatesoft.com... > Just a quick note to let everyone know that I'm working as fast as I can > right now on wrapping up the .NET data provider and the upcoming 1.07 > release. It shouldn't be more than a few more days, but it will simply be > ready "when it's ready". The VS2005 design-time integration is coming > along, but is fairly substantial and is the main thing holding up things at > this point. > > 1.07 includes new functionality in the form of a SELECT statement RANGE > clause for applying ranges to result sets to limit which rows appear in the > result set. This is required for the .NET provider to allow for pagination, > and is also very nice for the VCL products in order to restrict the work > required to populate a result set. If used with parameters instead of > constant values, you can modify the range without requiring the query to be > re-prepared. Furthermore, if you increase the end value of the range > incrementally via parameters, ElevateDB will simply continue from where it > left off in terms of populating the result set. For example, if you start > out with: > > SELECT * FROM MyTable > RANGE 1 TO 10 > > ElevateDB will only populate 10 rows into the result set. > > If you then use: > > SELECT * FROM MyTable > RANGE 100 TO 110 > > ElevateDB will populate the rows from 11 through 110. This means that if > you use: > > SELECT * FROM MyTable > RANGE 20 TO 30 > > the rows will already have been generated, thus requiring no more work on > the part of ElevateDB. > > One caveat, however, is that using the RANGE clause automatically results in > an insensitive result set. Also, this clause doesn't limit the amount of > work that ElevateDB has to do for aggregate or ordered queries that must > generate the entire result set before selecting ranges. Please don't ask me > about specific variations on ORDER BY clauses in terms of existing indexes - > initially the rules are exactly as stated and EDB doesn't optimize for > specific situations where an index might exist for the ORDER BY. > > Finally, the MaxRowCount property will be gone as of 1.07 due to the new > RANGE functionality. Having both is just simply too confusing for > developers and it is best if only the RANGE functionality exists for > limiting rows. > > -- > Tim Young > Elevate Software > www.elevatesoft.com > > |
Mon, Dec 10 2007 12:18 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Harry,
<< Is a solution there already in 1.07 that solves the problem of the (dis)connect thread in the NG where you stated: >> Not yet, but I'll see if I can squeeze it in. If not, I can get something done soon thereafter. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Dec 11 2007 2:00 PM | Permanent Link |
"Stefano Monterisi" | Hi Tim,
Select...range seems to be the pioneer of partial fetching (or server on demand) next big feature, true? Stefano Monterisi |
Tue, Dec 11 2007 2:33 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Stefano,
<< Select...range seems to be the pioneer of partial fetching (or server on demand) next big feature, true? >> Yes, it uses partial fetching when it can (non-aggregate queries, etc.), so you can do a SELECT * FROM MyTable RANGE 1 TO 10 on a 1 million row table and it will only fetch the first 10 rows. This is true for both local and remote sessions also. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Dec 12 2007 4:15 AM | Permanent Link |
"Stefano Monterisi" | Tim,
great! one questions: it's possibile to imagine that I can set a EDB property (like Devexpress does in its latest .net grid : ServerMode) and I can show my grid immediately, filled with only visible records,...... and grid automatically fetch necessary records on scroll or current operation ? So I can manage million of records on demand without initial slow loading (with all memory related problems) ? Shortly, can you apply also ranges natively managed by a property? If this is true, EDB become really a great DB..... Infact I love also Firebird + Fibplus (but I use always Dbisam as my main database) because it permits me to fetch data on need...without slowdown, expecially on remote connections. Tim, please work hardly on this; this is a big features. Good job, Stefano Monterisi "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> ha scritto nel messaggio news:751261D2-1958-4CF2-9E15-1202E437A441@news.elevatesoft.com... > Stefano, > > << Select...range seems to be the pioneer of partial fetching (or server > on demand) next big feature, true? >> > > Yes, it uses partial fetching when it can (non-aggregate queries, etc.), > so you can do a SELECT * FROM MyTable RANGE 1 TO 10 on a 1 million row > table and it will only fetch the first 10 rows. This is true for both > local and remote sessions also. > > -- > Tim Young > Elevate Software > www.elevatesoft.com > > |
Wed, Dec 12 2007 2:33 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Stefano,
<< it's possibile to imagine that I can set a EDB property (like Devexpress does in its latest .net grid : ServerMode) and I can show my grid immediately, filled with only visible records,...... and grid automatically fetch necessary records on scroll or current operation ? >> UI operations with grids are completely independent from EDB. It depends upon which grid you're using and how it behaves as to how many rows are fetched. With the TDBGrid that comes with Delphi, EDB always has, and always will, only retrieve the rows required to fill the visible rows in the grid. You need to remember that "fetching" and "row population" are two completely separate things. Fetching involves how many rows are retrieved from the ElevateDB Server for a given operation, and involves using the TEDBTable/TEDBQuery RemoteReadSize property to control how many rows are fetched at a time. Row population involves how many rows are being populated into a result set during the query execution, and will be controlled in 1.07 via the RANGE clause for a query. Row population is strictly a server-side operation and has nothing to do with the fetching. You could use a RANGE clause of 1 to 10 to limit the row population to 10 rows in the result set, and then still fetch each row one-by-one by using a RemoteReadSize of 1. << So I can manage million of records on demand without initial slow loading (with all memory related problems) ? >> Yes. Of course, you can do that now anyways with RequestSensitive:=True and sensitive result sets. << Shortly, can you apply also ranges natively managed by a property? >> Do you mean ranges as in the SetRange/CancelRange methods ? -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Dec 13 2007 6:00 AM | Permanent Link |
"Stefano Monterisi" | Hi Tim,
> UI operations with grids are completely independent from EDB. It depends > upon which grid you're using and how it behaves as to how many rows are > fetched. With the TDBGrid that comes with Delphi, EDB always has, and > always will, only retrieve the rows required to fill the visible rows in > the grid. I agree with you. > > You need to remember that "fetching" and "row population" are two > completely separate things. Fetching involves how many rows are retrieved > from the ElevateDB Server for a given operation, and involves using the > TEDBTable/TEDBQuery RemoteReadSize property to control how many rows are > fetched at a time. Row population involves how many rows are being > populated into a result set during the query execution, and will be > controlled in 1.07 via the RANGE clause for a query. Row population is > strictly a server-side operation and has nothing to do with the fetching. > You could use a RANGE clause of 1 to 10 to limit the row population to 10 > rows in the result set, and then still fetch each row one-by-one by using > a RemoteReadSize of 1. > > << So I can manage million of records on demand without initial slow > loading (with all memory related problems) ? >> > > Yes. Of course, you can do that now anyways with RequestSensitive:=True > and sensitive result sets. Ok. > << Shortly, can you apply also ranges natively managed by a property? >> > > Do you mean ranges as in the SetRange/CancelRange methods ? No, "Classic" ranges are another thing, you known very well I intend if is possible to set always a property of table/query (for.ex. RowResultSet = 100) instead of pass RANGE to SQL statement; The real need, Tim, is to show quickly enought rows for populate controls and grid, and populate data , at client level, when user need. It's only a performance apparence......user don't want see a empty grid and a wait message....this is (insensitive result sets). Good job, Stefano Monterisi |
Fri, Dec 14 2007 12:31 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Stefano,
<< No, "Classic" ranges are another thing, you known very well I intend if is possible to set always a property of table/query (for.ex. RowResultSet = 100) instead of pass RANGE to SQL statement; >> Yes, but by using parameters for the RANGE clause: SELECT * FROM MyTable RANGE :FromRow TO :ToRow and then you can just manually prepare the query and then keep executing the query with new parameters. Any time the :ToRow parameter exceeds the max rows generated for the result set so far, EDB will go grab more rows, if there any left. -- Tim Young Elevate Software www.elevatesoft.com |
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 |