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

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
>
>

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

Hi Tim,
Select...range seems to be the pioneer of partial fetching (or server on
demand) next  big feature, true?

Stefano Monterisi

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

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
>
>

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

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

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