For any ResultSets of a database query Database (external): postgres Tested on Linux and Windows The application failed to give you the TypeName for a column. (The TypeName gives you the Datatype for the specified column.You need the TypeName to execute later the right method ...getString, getLong etc.) This behavior only occurs for the first column in the first row of a ResultSet. For the next columns in the ResultSet or the next rows it works. DIM sRow AS STRING DIM oRow AS OBJECT while oResult.next sRow = oResult.columns.ElementNames(0) 'First Column Name of the ResultSet oRow = oResult.columns.getByName(sRow) 'access to a com.sun.star.sdb.ODataColumn print oRow.TypeName 'empty, although I got the column WEND REM Workaround: insert a line with the instruction com.sun.star.sdb.ODataColumn.Type while oResult.next sRow = oResult.columns.ElementNames(0) oRow = oResult.columns.getByName(sRow) oRow.Type 'inserted here an instruction print oRow.TypeName 'now it works WEND
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.) I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
REM You need a resultset oResult from a database query to reproduce this, sorry... Function Read_oResult(oResult AS Object) 'reads a ResultSet from a Database query and gives an array back (only the first row of a resultset) DIM var() DIM count_columns AS Integer DIM i AS Integer DIM sDataTyp_Row AS String DIM sName_Column AS String DIM n as Integer DIM count_rows as INTEGER 'retrieve the number of rows oResult.last count_rows = oResult.getRow oResult.beforefirst if count_rows = 0 then Read_oResult = null else count_columns = oResult.columns.count for i = 0 to count_columns-1 'see bugreport ttps://bugs.documentfoundation.org/show_bug.cgi?id=114464 ' inserted the next line with no use but only if inserted, oResult.columns.ElementNames(i)).TypeName works ' I need the datatype later to read the data with oResult.getInt...etc. ' to reproduce - just comment the next line out oResult.columns.getByName(oResult.columns.ElementNames(i)).Type sDataTyp_Row = oResult.columns.getByName(oResult.columns.ElementNames(i)).TypeName print sDataTyp_Row NEXT i end if ' .....do more to read the resultset in var() Read_oResult = var() End Function
Created attachment 156080 [details] Test Base-Doc with HSQLDB - not showing the bug It's always best to provide a testcase to be used immediately instead of having to construct one, which would be necessary when a PostgreSQL database is used, so I thought it best to create a simple base document using HSQLDB with one table having two columns and two rows. Unfortunately, the problem does not occur in this case. I do attach the document, nevertheless, so that you can look at it and see if I did not understand you correctly: "Test Base-Doc with HSQLDB - not showing the bug". Open the document, then start the only macro there is, it will list the two TypeNames and the contents of the columns, so you can see that it's in fact the first row. The code is restricted to the absolutely necessary. There is no form document. I then added a similar message box in on of my applications that uses MariaDB, but there again I could not reproduce the error. The application in this case is Calc, hence no reading of the database can have occured before the statement is executed that displays the message, which is the first situation where a rowset is used. You did not provide information about the LibO version. I tested in 6.3.3.2. I don't know how to test older versions in connection with base (for other modules there is no problem, but I don't know how to cop with older Java versions in parallel). So I cannot confirm the bug, and I can only offer two hypotheses: - You used an older LibO version - It's a problem connected with PostgreSQL But these are only assumptions, with no facts supporting them or making them probable.
it seems you're using an old version of LibreOffice. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Thank you for trying to reproduce the Bug. I don't have this strange behaviour anymore. Maybe it had something to do with the postgres Driver. I still use an old Version of libre Office 5.2.7. We can close the Bugreport. Thanx for your help!