Hello, > If the parameter fits in a Long (it is the case since our 2 schemas > work the same and SQLServer uses a long), what would happen if I use > the SQLServer generated model on the Oracle DB? Is there some > conversion or it would just fail saying that "BIGINT" is not > applicable for Oracle?
You can use either one of the generated artefacts on the other database. Ultimately, the difference will mainly affect variable binding: // The SQL Server generated artefacts will use CallableStatement.setLong() CallableStatement.getLong() // The Oracle generated artefacts will use CallableStatement.setBigDecimal() CallableStatement.getBigDecimal(); In general, the JDBC specification doesn't make a difference. But this is not thoroughly integration tested, so I'd expect some remote corner-cases. Examples: - When binding NULL to unsupported data types - When formally casting bind values in stored function parameters used in SQL >From the combination you're using, I'd expect you be better off using SQL Server generated artefacts against your Oracle database, avoiding packages, UDT's, ARRAY types, REF CURSORs (which are not yet supported in jOOQ's SQL Server integration). > On a related topic, if a field is Boolean (BIT) on SQLServer but a > Byte (TINYINT) on Oracle (with values 0=false, 1=true), [...] You probably mean NUMBER(1) on Oracle? > [...] would the > SQLServer model work on an Oracle DB with some sort of automatic > conversion (e.g.: from 1 to TRUE)? Yes. The SQL Server generated artefacts will apply CallableStatement.setBoolean() CallableStatement.getBoolean() Both of these methods are also implemented by the Oracle JDBC driver, which treats booleans as 1/0 internally. jOOQ will be oblivious of this, though and receive true/false. With Oracle, when executing the following query: System.out.println( create.select(val(true), val(false)).fetch()); You'll get: +----+-----+ |true|false| +----+-----+ |true|false| +----+-----+ Hope this helps Cheers Lukas
