Description: LO7.1 SDBC connection to FIREBIRD4 fails to display user table-data when rows extend beyond visible window ... Win7(64)(i7+32gbRAM+SSD),java(+jaybird)8,LO7.1.2 + .sdbc connection to Firebird4 , using openCL, to reproduce: create table with enough columns to extend beyond visible window + fill some rows with dummy data so that they extend below the visible window >>> save >>> close table >>> open the table again .... result: a grey window with menu-bar only is shown (no table)...if 'reload' button is selected then get "data cannot be loaded" message ... also window 'x' close button does not work, but menu-bar 'close' button does work... the whole time main LO app remains responsive, and all the data from the same 'un-viewable/un-loadable' table can be properly viewed by SELECT * QUERY in usual manner. (and seem fine in FirebirdPRO manager) small tables (ie that fit in viewing window) also seem to work fine however trying to create a "TABLE_VIEW" of the problem tables directly in LO causes instant LO crash ... Something is definatley going wrong here :/ (LoveYouLibre!) Steps to Reproduce: 1.see description 2. 3. Actual Results: failure to open tables and/or app crash Expected Results: normal behaviours :) Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: openGL4.6
@trowel : when you write that you connect via SDBC, is this a file based connection or a server-based connection to the Firebird 4 data ? You also mention Jaybird 8, so does that mean that you're connecting to FB4 data via a JDBC instead, and not SDBC ?
https://bugs.documentfoundation.org/show_bug.cgi?id=141846#c20 in which it is mentioned that the SDBC driver doesn't yet support connection to a FB server, rather than as a direct file connection. This might also have a bearing on your problem, irrespective of the known on-disk structure issues associated with FB4(v13), which are an inherent problem of Firebird itself.
arrg - I did in fact mean JDBC (not sdbc)...
...otherwise all comments still pertain (i cant edit the original bug description:/)
MoreInfo: ...same problem with LO7.2 (portable version-x86?)( on win7(64)) `
....had same results with previous LO and FB3, so (eventually) re-checked jaybird documentation; https://www.firebirdsql.org/file/documentation/drivers_documentation/java/4.0.x/release_notes.html#new-jdbc-protocol-prefix-jdbcfirebird "Historically, the JDBC protocols supported by Jaybird have used the prefix jdbc:firebirdsql:. We have now added support for jdbc:firebird: as an alternative prefix. This prefix was previously only supported in the OpenOffice.org/LibreOffice pure Java variant. Jaybird now supports the following URL prefixes (or JDBC protocols): Pure Java jdbc:firebirdsql: jdbc:firebirdsql:java jdbc:firebird: (new) jdbc:firebird:java: (new) Native jdbc:firebirdsql:native: jdbc:firebird:native: (new) Embedded jdbc:firebirdsql:embedded: jdbc:firebird:embedded: (new) Local jdbc:firebirdsql:local: jdbc:firebird:local: (new) OpenOffice.org/LibreOffice pure Java variant jdbc:firebird:oo: jdbc:firebirdsql:oo: " I had missed the " :oo: " segment in the datasource somehow !!!(i got the original string from other FB documention/related-sites, so maybe these are out-of-date ?) Thus, when connecting to FB3/4 from LO using JDBC the datasource should have been: firebirdsql:oo:DAISY7-PRO/3050:d:\\FLOP.FDB not: firebirdsql:DAISY7-PRO/3050:d:\\FLOP.FDB ... I think this closes the bug-issue, but some unclear online info and documentation (mainly on FB side of things) has lead me here, so hopefully this will be useful info!
...simply add " :oo: " into the "datasource" string in edit>database>properties from the opened .odb database in LO, save , close and re-open the file in LO ... the broken tables described above are now fixed !!! 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 :/. Anyway, ThankYouFirebird & LoveYouLibre
(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 ;-)