This happens on 10.04.2 LTS (x86_64) linux 2.6.32-30-generic with OO
3.2.0 as well.

Its not just OO Base.. general OO Basic macro execution in OO Calc
spreadsheets execute 4 to 5 times slower than with previous JRE (22).

As a test case - creating a JDBC database connection "datasource1" (be
sure to install necessary java class files for particular databse) and
use the following macro in a Calc spreadsheet:

REM  *****  BASIC  *****

Global Pipe_connectedDatabase As Boolean        ' Are we connected to the 
database?
Global Pipe_dConn as Variant
Global Pipe_dStat as Variant

function pipe (f_s as string) as variant
    on error goto err_h

        Dim dataType As Long            ' What type of data was returned by the 
database?
        dim url as String
        dim driver as String
        dim dBase as Variant
        dim oDB as Variant
        dim oManager as Variant
        dim oMetaData as Variant
        dim connArgs(0) As New com.sun.star.beans.PropertyValue
        ' These declarations below are for casting data types around in BASIC
        Dim tmpDouble As Double         ' Temporary holder for a double 
datatype, for inserting into Any
        Dim tmpString As String         ' Temporary holder for a string 
datatype, for inserting into Any 

        ' Actual database query
        if Pipe_connectedDatabase = false then
        dBase = createUnoService("com.sun.star.sdb.DatabaseContext")
        oDB = dBase.getByName("datasource1")
        url = oDB.URL
        driver = oDB.Settings.JavaDriverClass
        oManager = createUnoService ("com.sun.star.sdbc.DriverManager")
        connArgs(0).name = "JavaDriverClass"
        connArgs(0).value = driver
        Pipe_dConn = oManager.getConnectionWithInfo (url, connArgs)
        Pipe_connectedDatabase = true
        Pipe_dStat = Pipe_dConn.createStatement()
    end if
        oSet = Pipe_dStat.executeQuery (f_s) 
        

        ' Datatype casting logic
        if oSet.next () then
                ' Get a LONG representation of the type of data that was 
returned by the
                ' database
                dataType = oSet.getMetaData().getColumnType(1)
                Select Case dataType

                        Case com.sun.star.sdbc.DataType.CHAR
                                tmpString = RTrim(oSet.getString(1))
                                ret_val = tmpString

                        Case com.sun.star.sdbc.DataType.SMALLINT
                                tmpDouble = oSet.getDouble(1)
                                ret_val = tmpDouble

                        Case com.sun.star.sdbc.DataType.INTEGER
                                tmpDouble = oSet.getDouble(1)
                                ret_val = tmpDouble

                        Case com.sun.star.sdbc.DataType.DECIMAL
                                tmpDouble = oSet.getDouble(1)
                                ret_val = tmpDouble

                        Case com.sun.star.sdbc.DataType.VARCHAR
                                tmpString = RTrim(oSet.getString(1))
                                ret_val = tmpString

                        Case com.sun.star.sdbc.DataType.DATE
                                tmpString = Trim(oSet.getString(1))
                                ret_val = tmpString

                        Case Else
                                ' Insert unknown types as string
                                tmpString = RTrim(oSet.getString(1))
                                ret_val = tmpString

                End Select
        
        else
          ret_val = "##NULL##"
        end if
        pipe = ret_val
        exit function
err_h:

        if Pipe_connectedDatabase = true then
                Pipe_dConn.close()
                Pipe_connectedDatabase = false
        endif

        pipe = "##ERROR##"
        exit function
end function


To test it..  in a cell enter:  =pipe("select count(*) from sometable")  

(sometable being the name of actual database table)

This should return the number of rows and insert it in the cell as a
value (If you only get ##ERROR## - suspect jdbc connectivity issue/java
class path issue).

This alone doesn't reveal performance issue.. BUT.. copy and paste this
to 1000 cells.. and compare the performance with 22 and 24.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/724217

Title:
  Very slow openoffice base after update to java-6-sun-1.6.0.24jre

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to