Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Enhancement Requests and Suggestions » View Thread |
Messages 1 to 10 of 15 total |
New Features request |
Tue, May 22 2007 7:48 AM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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. What, 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 AM | Permanent 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 . 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 > > << 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. What, 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 . Stefano Monterisi |
Wed, May 23 2007 3:04 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 PM | Permanent 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! -- Charalabos Michael - [Creation Power] - http://www.creationpower.gr |
Thu, May 24 2007 4:21 AM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 AM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 AM | Permanent Link |
"Stefano Monterisi" | Perfect!
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 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Friday, March 29, 2024 at 03:30 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |