https://bugs.documentfoundation.org/show_bug.cgi?id=145343
--- Comment #8 from Alex Thurgood <ipla...@tuta.io> --- (In reply to trowelandmattock from comment #7) > I cant possibly imagine why this would be the case, since tables with only a > few rows (<c.30) are fine, but tables with more rows (>c.60) break :/. > Thanks for clearing this up, and always useful to have that driver connection string change documented somewhere. Unfortunately, for us, the default is probably hardcoded in the default connection string proposed when the connection dialog is set up. I imagine that this would need changing at some stage. With regard to the display limit, I don't fully understand the mechanism, but from what I recall, the UI in LO caches a part of the resultset temporary memory for the purpose of display in the gridview control. How LO actually gets that data in the first place, presumably from the (x)DBC bridge created when the database context is created, might be the reason for the disparity in behaviour between what you see with :firebirdsql: and :firebirdsql:oo: I vaguely recall that the limit in UI redraw cache is somewhere between 40 to 60 rows depending on the amount of data (i.e. also the number, field data type and stored data) that gets pulled into the cache. There are at least a few devs who understand how this works, I'm just the binman ;-) -- You are receiving this mail because: You are the assignee for the bug.
