Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 15 total
Thread New Features request
Tue, May 22 2007 7:48 AMPermanent Link

"Stefano Monterisi"
Hi Tim,
I have used in one project Fibplus with Firebird database (they works
wonderful)....
I want suggest you to insert in EDB the best features I can obtain with
those 2 products;
1) Partial-incremental Fetching of records; This increase tremendously the
speed of UI, especially with grids, etc......and user don't wait if he need
to see few records at the top of a big query.
2) Macro substitution in queries body; This  features permits to assign at
runtime some parts of the query sql  (tables, conditions, etc..) and not
only parameters....
3) I want that EDB will can have the performance of those 2 products;
Firebird is very fast in queries; I hope that EDB can be compete with it in
the near future in term of speed. (I have noted rilevent difference).

I have appreciated the great job that you are making on SQL and SP in EDB.

Thanks in advance,

Stefano Monterisi


Tue, May 22 2007 8:46 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Stefano,

<< 1) Partial-incremental Fetching of records; This increase tremendously
the speed of UI, especially with grids, etc......and user don't wait if he
need to see few records at the top of a big query. >>

Are you referring to fetching rows *while* the query is still executing, or
*after* the query is done executing ?

<< 2) Macro substitution in queries body; This  features permits to assign
at runtime some parts of the query sql  (tables, conditions, etc..) and not
only parameters.... >>

<< 3) I want that EDB will can have the performance of those 2 products;
Firebird is very fast in queries; I hope that EDB can be compete with it in
the near future in term of speed. (I have noted rilevent difference). >>

You'll have to be more specific than that. SmileyWhat, in particular, is EDB
slower than Firebird when it comes to execution ?

Thanks,

--
Tim Young
Elevate Software
www.elevatesoft.com

Wed, May 23 2007 4:18 AMPermanent Link

"Stefano Monterisi"
Tim,

> << 1) Partial-incremental Fetching of records; This increase tremendously
> the speed of UI, especially with grids, etc......and user don't wait if he
> need to see few records at the top of a big query. >>
>
> Are you referring to fetching rows *while* the query is still executing,
> or *after* the query is done executing ?

Fibplus+Firebird (I don't known (I have no time for investigate)  if is
Fibplus or Firebird that permits this features..) allow incremental fetching
of  records always (as an option); I have noted that even big queries return
immediately records for fill the grid (only records visible); I have also
noted that if I go to the last record in the grid after ten seconds (when
the query I think is already executed)  it fetch last records, so I think
that the fetching is performed always, if records aren't in the buffer. But
this is an option that can be true or false; for reports or special
calculations incremental fetching is not so important , but for the part of
application that  interact directly  with the user, this features permits a
great advantage. This is perfect with grids, lookups, searches, and data
navigation, especially over slow connections (remote, etc). Please try
yourself those products (only for verify those features, naturally Smiley.
With this option we can use always queries instead tables, with a great
speed. (working with tables is fast, but open and close queries is slower
now).

>
> << 2) Macro substitution in queries body; This  features permits to assign
> at runtime some parts of the query sql  (tables, conditions, etc..) and
> not only parameters.... >>

Fibplus works with Firebird & c.; for this it is optimized for use SQL and
not classic tables datasets;
The fibplus dataset in effect  perform standard select, insert, update,
delete command (that you can modify as you want); It offer the capabilities
to pass, at runtime, not only parametes, but also variable parts of the SQL
like macro variables. So I can pass parameters and also table name and where
clause (for ex.).
For better information , please try yourself Smiley

>
> << 3) I want that EDB will can have the performance of those 2 products;
> Firebird is very fast in queries; I hope that EDB can be compete with it
> in the near future in term of speed. (I have noted rilevent difference).
>  >>


> You'll have to be more specific than that. SmileyWhat, in particular, is EDB
> slower than Firebird when it comes to execution ?

Firebird is optimize for queries; Honestly, I have seen that it is faster a
lot over Dbisam (EDB is still in work, so I cannot compare them); Naturally
this is true if I use SQL and queries;  I think that the incremental
fetching I have used, showing records instantaneously, can pull me in
deceit,..... but I think it is very fast.
I repeat, I have used Fibplus+Firebird;
If  I use other components for acces Firebird, the result change (and is
slower).
EDB is now voted to SQL than table access (if we want use it in the future
across win32,.net and others) and those features are very comfortable.
Please consider my suggest and try yourself;
All that I want.....is EDB more faster possible (not for your interest , for
my customers Smiley.

Stefano Monterisi




Wed, May 23 2007 3:04 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Stefano,

<< Fibplus+Firebird (I don't known (I have no time for investigate)  if is
Fibplus or Firebird that permits this features..) allow incremental fetching
of  records always (as an option); I have noted that even big queries return
immediately records for fill the grid (only records visible); >>

I'll have to check it out, but incremental fetching *while* the query is
still executing is a bit more complicated than what the TDataSet
architecture may allow in terms of displaying rows.  Using a simple grid
that isn't data-bound, it is easy to do incremental fetching.


<< Firebird is optimize for queries; Honestly, I have seen that it is faster
a lot over Dbisam (EDB is still in work, so I cannot compare them); >>

EDB is faster than DBISAM in most cases.

<< Naturally this is true if I use SQL and queries;  I think that the
incremental fetching I have used, showing records instantaneously, can pull
me in deceit,..... but I think it is very fast. >>

Yes, if the fetching is retrieving rows before the query is done executing,
then that would give a false impression.  The best way to find out is to do
a timing that includes retrieving the last row in the query result set.

--
Tim Young
Elevate Software
www.elevatesoft.com

Wed, May 23 2007 3:41 PMPermanent Link

Charalabos Michael
Hello Tim,

> << Fibplus+Firebird (I don't known (I have no time for investigate)  if is
> Fibplus or Firebird that permits this features..) allow incremental fetching
> of  records always (as an option); I have noted that even big queries return
> immediately records for fill the grid (only records visible); >>
>
> I'll have to check it out, but incremental fetching *while* the query is
> still executing is a bit more complicated than what the TDataSet
> architecture may allow in terms of displaying rows.  Using a simple grid
> that isn't data-bound, it is easy to do incremental fetching.
>
>
> << Firebird is optimize for queries; Honestly, I have seen that it is faster
> a lot over Dbisam (EDB is still in work, so I cannot compare them); >>
>
> EDB is faster than DBISAM in most cases.
>
> << Naturally this is true if I use SQL and queries;  I think that the
> incremental fetching I have used, showing records instantaneously, can pull
> me in deceit,..... but I think it is very fast. >>
>
> Yes, if the fetching is retrieving rows before the query is done executing,
> then that would give a false impression.  The best way to find out is to do
> a timing that includes retrieving the last row in the query result set.

This feature seems good. I vote too! Smiley

--
Charalabos Michael - [Creation Power] - http://www.creationpower.gr
Thu, May 24 2007 4:21 AMPermanent Link

"Stefano Monterisi"
Hi Tim,

> << Fibplus+Firebird (I don't known (I have no time for investigate)  if is
> Fibplus or Firebird that permits this features..) allow incremental
> fetching of  records always (as an option); I have noted that even big
> queries return
> immediately records for fill the grid (only records visible); >>
>
> I'll have to check it out, but incremental fetching *while* the query is
> still executing is a bit more complicated than what the TDataSet
> architecture may allow in terms of displaying rows.  Using a simple grid
> that isn't data-bound, it is easy to do incremental fetching.

Of course, this feature isn't simple or immediate to implement...

>
> << Firebird is optimize for queries; Honestly, I have seen that it is
> faster a lot over Dbisam (EDB is still in work, so I cannot compare them);
>  >>
>
> EDB is faster than DBISAM in most cases.

If we are talking about is because EDB (with its RI, SP etc.) is the good
start point for this new features.


> << Naturally this is true if I use SQL and queries;  I think that the
> incremental fetching I have used, showing records instantaneously, can
> pull me in deceit,..... but I think it is very fast. >>
>
> Yes, if the fetching is retrieving rows before the query is done
> executing, then that would give a false impression.  The best way to find
> out is to do a timing that includes retrieving the last row in the query
> result set.

I will try tests between EDB and Fibplus+Firebire with the same data and the
same forms and conditions (grids, etc.); Then we can consider differences.

Good Job.

Stefano Monterisi

> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Thu, May 24 2007 5:26 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Stefano,

<< Of course, this feature isn't simple or immediate to implement... >>

Well, what I was getting at was that it may be downright impossible to do
given the TDataSet architecture and still retain dynamic result set cursors.

--
Tim Young
Elevate Software
www.elevatesoft.com

Fri, May 25 2007 4:03 AMPermanent Link

"Stefano Monterisi"
Tim,
> << Of course, this feature isn't simple or immediate to implement... >>
>
> Well, what I was getting at was that it may be downright impossible to do
> given the TDataSet architecture and still retain dynamic result set
> cursors.

Infact, it needs a more C/S approach (with SQL for insert, update,
etc...like deltas management)   than tradizional Tdataset approach....

Good job, Tim.

Stefano

Fri, May 25 2007 2:16 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Stefano,

<< Infact, it needs a more C/S approach (with SQL for insert, update,
etc...like deltas management)   than tradizional Tdataset approach.... >>

Correct.  In 1.03 we put in the ground work for updateable views with
instead of triggers, so eventually that will be extended to all query result
sets.

--
Tim Young
Elevate Software
www.elevatesoft.com

Mon, May 28 2007 11:52 AMPermanent Link

"Stefano Monterisi"
Perfect! Smile

Stefano

>
> Correct.  In 1.03 we put in the ground work for updateable views with
> instead of triggers, so eventually that will be extended to all query
> result sets.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Page 1 of 2Next Page
Jump to Page:  1 2
Image