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.
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_connectedD atabase 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? star.beans. PropertyValue
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.
' 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 atabase = false then e("com. sun.star. sdb.DatabaseCon text") ("datasource1" ) JavaDriverClass star.sdbc. DriverManager" )
connArgs( 0).name = "JavaDriverClass"
connArgs( 0).value = driver getConnectionWi thInfo (url, connArgs)
Pipe_connected Database = true createStatement () executeQuery (f_s)
if Pipe_connectedD
dBase = createUnoServic
oDB = dBase.getByName
url = oDB.URL
driver = oDB.Settings.
oManager = createUnoService ("com.sun.
Pipe_dConn = oManager.
Pipe_dStat = Pipe_dConn.
end if
oSet = Pipe_dStat.
' Datatype casting logic a().getColumnTy pe(1)
if oSet.next () then
' Get a LONG representation of the type of data that was returned by the
' database
dataType = oSet.getMetaDat
Select Case dataType
Case com.sun. star.sdbc. DataType. CHAR getString( 1))
tmpString = RTrim(oSet.
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 getString( 1))
tmpString = RTrim(oSet.
ret_val = tmpString
Case com.sun. star.sdbc. DataType. DATE getString( 1))
tmpString = Trim(oSet.
ret_val = tmpString
Case Else getString( 1))
' Insert unknown types as string
tmpString = RTrim(oSet.
ret_val = tmpString
End Select
else
ret_val = "##NULL##"
end if
pipe = ret_val
exit function
err_h:
if Pipe_connectedD atabase = true then dConn.close( ) connectedDataba se = false
Pipe_
Pipe_
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.