Interesting approach. It should work, but the trouble with it is wasted memory; as all those private members are still initialized in the base clase and then not used.
Andrey, SQLContainer started as an add-on and was later integrated into Vaadin as a core feature; it was never a simple demonstration implementation.
After more testing, I’m finding the workaround still has issues. Scrolling through my table, it frequently spends several seconds alternating between loading rows starting at index 0 and 150, a hundred times, before settling where it should be… which may be in the thousands. After it does this, I also get some rows rendered only a few pixels high, which is an odd side effect to have.
I think it’s time to try the Lazy Query Container plugin… I hope it works better.
Ooops! This is my bug. Today I will try to fix it.
I gave up on SQLContainer and switched to Lazy Query Container. It was a lot of work to convert, but LQC absolutely works better. To help others with the conversion, I created a wiki page with the results of my efforts.
https://vaadin.com/wiki/-/wiki/Main/Using+JDBC+with+Lazy+Query+Container+and+FilteringTable
Hi Adam. I’m using Vaadin 7.4.3 and i’m still with the same problem. Using LQC really solves your problem? I will convert my code so…
Hi guys,
Is this issue browser independent?
I’m using 7.6.3 & I don’t see any problem with 100K data on al browser other than IE11.
Well guys, I opened this thread days ago and updated it recently:
https://vaadin.com/forum#!/thread/16170167
My conclussion is not the same but I think the bug is definitely the same. Maybe they are complementary: see my comment about surpassing the searched item in the last iteration of the while loop. As it gets incremented in +200 item batches, I think it’s possible it got skipped on the last one as the condition for ending the while gets true but the existance in that last batch hasn’t been tested.
I think we are suffering from the same bug. It’s incredible how this has been documented from 5 years now and there’s no single fix nor any comment from the staff on this. Moreover, we are out of luck as SQLContainer has been
deprecated
on v8.
If anyone has a (final?) recommendation on how to overcome this, it would be a lifesaver to hear it… 
You could have a look at LazyEntityContainer which works for me (with some smaller adaptions[*]
) like a charm. This AddOn is available for Vaadin 7.x as well as 8.x (but I don’t know how long it’s supported for 7.x.)
But if this is a “final” recommendation … your decision 
[*]
The EntityQuery cannot proper deal with sortings on nested Entities that might be null because it generates a very strict cross join (in fact an inner join). I needed to explicitly define a “proper join chain”.
Thanks Volker; at first sight I tried to avoid LazyEntityContainer because I don’t want to change code in all my StatementDelegates and also I’m a bit reluctant of using add-ons, which you don’t know where they are going to be dropped…
Before seeing your answer I was about to report that I succeeded following instructions by Adam Fanello in post #14. They worked like a charm! The only doubt I had was how to assure that my own version of SQLContainer.java was being picked up instead of the framework’s one in the classpath, but after trial and error (and putting a couple of breakpoints in the source code just to be sure) this seems to be the case by default with Maven projects on NetBeans.
The code for updateOffsetAndCache(int index) differs a bit from what it looked like when the patch was released (the
cacheOverlap
property didn’t seem to exist then), but after some testing I think it’s safe to assume that it works properly in the following way:
private void updateOffsetAndCache(int index) {
int oldOffset = currentOffset;
currentOffset = (index / pageLength) * pageLength - cacheOverlap;
if(index - currentOffset <= pageLength){
currentOffset -= pageLength;
}
else if(index - currentOffset >= pageLength * 2){
currentOffset += pageLength;
}
if (currentOffset < 0) {
currentOffset = 0;
}
if (oldOffset == currentOffset && !cachedItems.isEmpty()) {
return;
}
getPage();
}And, of course, don’t forget to set up
public static final int CACHE_RATIO = 3;
As a final note, it would be nice if Vaadin team confirmed the patch is working and integrated it in v7.7.8…
If you’ve already got a solution - congrats 
BTW: Vaadin is on 7.7.10 now … but AFAICS there’s nothing reported to be done that affects the problem above.
Thanks for pointing out, Volker.
I have a “partial working”, non-optimal, absolutely-ugly solution. Partial because there are still issues - for instance, I have just discovered that trying to fetch the entire dataset at once with this method makes it freeze, too (I haven’t tested if it happened prior to applying the patch). Non-optimal because, as stated above, changing CACHE_RATIO to 3 makes the method fetch a lot more rows than it’s needed (and user report to exist other issues, also). And extremely ugly… I think I don’t need to explain why :P.
It’s a shame they are not willing to even take a look at it. Proposals on how to solve it are already there and it doesn’t seem a difficult fix; probably the ones who made it and used to what the algorithm is supposed to do, would solve it in a breeze. I simply don’t understand why.
Hey - it’s NOT ME who made it! I’m just a vaadin-user …
Of course, Volker xD. I made the proper edits to my comment; lol.