Firebird prepareStatement setFloat gives an sdbc error

[parsely]

linuxMint 21 fresh install, comes with LO
Version: 7.3.7.2 / LibreOffice Community
Build ID: 30(Build:2)
CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-GB (nl_NL.UTF-8); UI: nl-NL
Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.2
Calc: threaded

In one of the macros I use, a prepareStatement gives the error com.sun.star.sdbc.SQLexception …dbexception.cxx:462 if a float value is involved.
After stripping, the simplest code is

def test(oEvent):
    sSQL ='insert into "tblO-art" ("IDsub" , "IDart" , "IDunique" , \
                 "QTY" , "toeslag" , "override") values (?,?,?,?,?,?)'
 
 
    DatabaseContext =smgr.createInstanceWithContext("com.sun.star.sdb.DatabaseContext", ctx)
    DataSource = DatabaseContext.getByName("quote_front_FB")
    dbConnection = DataSource.getConnection( "","")
    pStmt = dbConnection.prepareStatement(sSQL)
    
    values = [123, 92, 92, 87.6, 1.3, "extra"]
    t = ["int","int","int","float","float","string"]

    for j in range(6):
        if t[j] == "int":
           pStmt.setInt(j+1,values[j])
        elif t[j] == "float":
           pStmt.setFloat(j+1,values[j])
        elif t[j] == "string":
           pStmt.setString(j+1,values[j])

What is wrong in the above attempt?

[Villeroy]

First blind shot: try setDouble

[karolus]

…
    values = [123, 92, 92, 87.6, 1.3, "extra"]
    types = ["int","int","int","float","float","string"]
    for pos, (value, _type) in enumerate(zip(values,types),1):
        if _type == "int":
           pStmt.setInt(pos, value)
        elif _type == "float":
           pStmt.setDouble(pos, value)
        elif _type == "string":
           pStmt.setString(pos, value)

do you see the difference?

[parsely]

Yes, I already marked the Villeroy response as the answer.

To be more specific, from the recordset.getMetaData() its for the
datatype NUMERIC - setDouble, FLOAT - setFloat, (and probably, not tested) DOUBLE - setDouble

[karolus]

@parsely

Yes, I already marked the Villeroy response as the answer.

I know, I was more interested in showing how to avoid this index fiddling.