Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 21 to 30 of 39 total |
I need accurate scrollbar! (And i guess many of EDB customers too) |
Sat, Dec 19 2009 7:30 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Leslie,
<< Tim, you already have a working solution, you already know how to implement RecNo support and I am going to assume that it can be adopted for EDB. >> Probably, but that's beside the point. I've already noted *many* times that the decision to not include logical row number support was due to performance, and not because it couldn't be done. << You seem to be kind of obsessed with the "RecNo support causes slow update performance on large datasets" problem. Why do not leave this in the hand of the user? If there was a "WITH/WITHOUT RECNO SUPPORT" parameter for CREATE/ALTER TABLE/VIEW/DATABASE the user could decide what is best. >> It's not that simple at all. The format of the indexes would need to change, along with almost all of the navigational code. Given that amount of other features that need implemented, this is simply not an important feature for us right now. As I told Michael already, I've got some ideas on some ways to deal with it, but nothing that will see even a test implementation for quite a while. -- Tim Young Elevate Software www.elevatesoft.com |
Sat, Dec 19 2009 7:39 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Leslie,
<< For other engines these three usually come from different vendors. It is a bonus that EDB includes all of them. But most (most likely all) other delphi DAC components handles RecNo on the client side in order to properly support grid components. So in this regard EDB DAC is missing an important, one might even say basic feature. >> You are comparing apples to oranges here. In most cases these other front-ends require that all rows in the result set be fetched into a static, client-side memory dataset in order to number each row. ElevateDB provides *live* access into tables and sensitive result sets/views, and therefore must be able to dynamically calculate a logical row number *quickly* in order to provide such logical row numbers. The only way to do this with B-Tree indexes is to store statistics in the indexes that allow you to aggregate the row position as the index is navigated. However, these same statisitics need to be updated during every index update, and will require updates to propogate up the index tree to the root node for *every single update*. That's a lot of extra I/O in any busy application, and that hurts performance and concurrency. Remember, for most database engines/servers, there is no such thing as opening a table directly or browsing a server-side sensitive result set or view, seeing all changes made by other sessions immediately. -- Tim Young Elevate Software www.elevatesoft.com |
Sat, Dec 19 2009 8:55 AM | Permanent Link |
Leslie | Tim,
You do not need to protect your decision, because it is your call not mine. Please, please, please read it again and try to understand it, because you did not! You are telling me things I already clearly understand about the technical part ... about your being capable of doing it ... sensitive datasets ... and frankly there is no way to counter the "too much work required part", it is the trump ace. But some day maybe you will have the time or you just get tired of this issue which makes you do it, and there is something above you have missed and might be useful. The design and programming practice is there, how EDB could be used with the minimal penalty yet having accurate scrollbars for most situations. The data needs to be displayed in grid and edited many times does not qualify for sensitive result sets, and that is the only thing you seem to care. Whenever this is the case it becomes difficult to work with EDB DAC components. I think you should try to think over how EDB can be used if you take sensitive resultsets out of the picture. |
Sat, Dec 19 2009 4:08 PM | Permanent Link |
Aage Johansen | Michael Baytalsky wrote:
> Leslie, > >> For other engines these three usually come from different vendors. It >> is a bonus that EDB includes all of them. But most (most likely all) >> other delphi DAC components handles RecNo on the client side in order >> to properly support grid components. > Examples, please. The way Firebird's DAC support recno is by executing > the same query several times including once with count(*) in order to > get RecNo. ... What do you mean by "Firebird's DAC" ? -- Aage J. If this is getting to far off topic, we'll just let this subthread die... |
Sun, Dec 20 2009 12:41 AM | Permanent Link |
Charalampos Michael | Dear Walter,
>> but simple that's the truth! > > The cost of having RecNo to performance is The Truth. > > Accurate and timely data access is The Truth. I don't think so ... The truth is that RecNo will have a perfomance hit and the perfomance hit depends on the implementation of the method used. -- Charalampos Michael - [Creation Power] - http://www.creationpower.gr |
Sun, Dec 20 2009 12:47 AM | Permanent Link |
Charalampos Michael | Dear Tim,
> Yes, especially since I already wrote one about 10 years ago called DBISAM. > Well, don't forget Eryk which helped too.I can't don't forget him and his aggressive attitude in some cases. Oh boy, i miss him and Ole too ... > It's not that it can't be done, it's that there are significant > downsides to it when you start to get into the 1 million+ row range. It may > not be your personal experience with your customers, but a lot of ElevateDB > customers have customers with very large amounts of data, and we cannot > afford to give up raw performance for the sake of something as petty as > scrollbar display. When it comes down to it, the choice is rather easy. Yes, include both index methods (as i can see leslie proposed that in a following answer) Then you have all your DBISAM customers happy and give them a reason to upgrade to EDB = $$$ for your company. Anyhow, i get used to have upgrade/changes of DB formats ... From Paradox->DBISAM v2->v3->v4->EDB v1->v2 -- Charalampos Michael - [Creation Power] - http://www.creationpower.gr |
Sun, Dec 20 2009 12:50 AM | Permanent Link |
Charalampos Michael | Dear Rita,
> Michael the solution is out there try rolling your own. > Tims taken care of the engine so its fast have you > even tried switching off the Devx grid scrollbars and > using the Tscrollbar component from the standard > vcl page. This is what it says in the help file. Apparently you haven't tried QGrid in with real world data over eg 20.000 records. > The scroll bar component creates a scroll bar that you can use to scroll the > contents of a window, form, or other control. In the OnScroll event handler, > you write code that determines how the control behaves when the user moves > the scroll bar. > The scroll bar component is not used very often, because many visual > components include scroll bars of their own and thus don't require > additional coding. For example, TForm has VertScrollBar and HorzScrollBar > properties that automatically configure scroll bars on the form. To create a > scrollable region within a form, use TScrollBox. Are you serious ? (as i can imagine not ...) Why to reinvent the wheel since QGrid does the same ? -- Charalampos Michael - [Creation Power] - http://www.creationpower.gr |
Sun, Dec 20 2009 12:52 AM | Permanent Link |
Charalampos Michael | Dear Michael,
> For what it's worth, IMO no serious RDBMS will provide RecNo. Having > switched > to Firebird and Oracle I miss many of DBISAM's features. I'm not sure > how they did it in Nexus but it does incur penalty. Therefore, I think your > best bet would be middle tier, where you could read the whole dataset into > memory fast and then do whatever you like with it, including having it > sorted > filtered and numbered. This is by far the best approach from the pow of > scalability and user experience. I'd say if you demand WAN access to data, > then middle tier should be a default option. The idea of EDB is to make better than DBISAM and not a crippleware ... There isn't need to use any Memory Dataset while using QGrid. It does the same thing! -- Charalampos Michael - [Creation Power] - http://www.creationpower.gr |
Sun, Dec 20 2009 12:52 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Aage,
<< What do you mean by "Firebird's DAC" ? >> DAC is short-hand for Data Access Components. -- Tim Young Elevate Software www.elevatesoft.com |
Sun, Dec 20 2009 12:54 AM | Permanent Link |
Charalampos Michael | Dear Tim,
> It's not that simple at all. The format of the indexes would need to > change, along with almost all of the navigational code. Given that amount of > other features that need implemented, this is simply not an important > feature for us right now. As I told Michael already, I've got some ideas on > some ways to deal with it, but nothing that will see even a test > implementation for quite a while. As i said you're a brilliant guy and you proved that on our e-mail conversation ... So, it's a matter of time EDB to be the best RMDBS out there. -- Charalampos Michael - [Creation Power] - http://www.creationpower.gr |
« Previous Page | Page 3 of 4 | Next Page » |
Jump to Page: 1 2 3 4 |
This web page was last updated on Thursday, July 4, 2024 at 06:12 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |