Re: (bug with ibatis+oracle odp.net provider ?) RE: problems with param mapping, and params becoming null on oracle

[Roberto Rabe <ro...@apache.org>]

It's not really a bug.  The ODP provider requires that the developer using
iBATIS.NET must specify every single VARCHAR2 field length using
parameterMaps since the provider expects it when setting the ADO.NET
command parameters.  Please try a really simple 1 field INSERT where a
parameterMap is used and the length is specified (use the Alpha or latest
source) to see if it works in your environment.

Roberto

On Mon, April 25, 2005 17:57, Maxime Levesque said:
>
>   Using MS's provider fixes the "null string / varchar2" bug
>
>  (to recapitulate : I call an insert statement with an object with
>   a few non null string properties, they end up as null in the DB,
>   however int and DateTime params in the same statement get inserted
>   fine)
>
>   I wasn't able to solve the bug by tracing the source code,
>   But I figure it must be an iBatis bug, since the test case works
>   with microsoft's client.
>
>   Here's a few questions :
>
>   - Is anyone out there using the oracle + odp.net combination ?
>   - Is the driver used in test suite ? (I noticed most of the test code
>     is for mysql and mssql...)
>
>  Thanks
>
> <?xml version="1.0" encoding="utf-8" ?>
>
> <providers>
> 	<clear/>
>
> 	<provider
> 		name="oracle10g"
> 		enabled="true"
> 		assemblyName="Oracle.DataAccess, Version=10.1.0.301,
> Culture=neutral, PublicKeyToken=89b483f429c47342"
> 		connectionClass="Oracle.DataAccess.Client.OracleConnection"
> 		commandClass="Oracle.DataAccess.Client.OracleCommand"
> 		parameterClass="Oracle.DataAccess.Client.OracleParameter"
>                 parameterDbTypeClass="Oracle.DataAccess.Client.OracleDbType"
> 		parameterDbTypeProperty="OracleDbType"
>
> dataAdapterClass="Oracle.DataAccess.Client.OracleDataAdapter"
> 	commandBuilderClass="Oracle.DataAccess.Client.OracleCommandBuilder"
> 		usePositionalParameters = "false"
> 		useParameterPrefixInSql = "true"
> 		useParameterPrefixInParameter = "false"
> 		parameterPrefix=":"
> 	/>
>
> 	<provider
> 		name="oracleClient1.0"
> 		description="MS Oracle provider V1.0.5"
> 		enabled="true"
> 		default="false"
> 		assemblyName="System.Data.OracleClient, Version=1.0.5000.0,
> Culture=neutral, PublicKeyToken=b77a5c561934e089"
> 		connectionClass="System.Data.OracleClient.OracleConnection"
>
> 		commandClass="System.Data.OracleClient.OracleCommand"
> 		parameterClass="System.Data.OracleClient.OracleParameter"
> 		parameterDbTypeClass="System.Data.OracleClient.OracleType"
> 		parameterDbTypeProperty="OracleType"
>
> dataAdapterClass="System.Data.OracleClient.OracleDataAdapter"
>
> commandBuilderClass="System.Data.OracleClient.OracleCommandBuilder"
> 		usePositionalParameters = "false"
> 		useParameterPrefixInSql = "true"
> 		useParameterPrefixInParameter = "false"
> 		parameterPrefix=":"
> 	/>
> </providers><?xml version="1.0" encoding="utf-8" ?>
>
> -----Original Message-----
> From: Ron Grabowski [mailto:rongrabowski@yahoo.com]
> Sent: Thursday, April 21, 2005 3:31 PM
> To: ibatis-user-cs@incubator.apache.org
> Subject: RE: problems with param mapping, and params becoming null on
> oracle
>
> Do normal inserts (without the transaction) work?
>
>  SqlMapper m = Mapper.get();
>  int id = (int)m.Insert("InsertUsager", u1);
>
> You can use an inline parameter map to tell IBatisNet what type your
> objects. Varchar2 referes to Orace.DataAccess.DbTypes.Varchar2 or
> whatever the full DbTypes namespace is for your provider.
>
>  <insert id="InsertUsager" parameterClass="Usager">
>   Insert Into Usagers (id, nom_usager, nom, prenom)
>   Values (UsagersSeq.nextVal, #NomUsager:Varchar2#, #Nom:Varchar2#,
> #Prenom:Varchar2#)
>  </insert>
>
> Its usually not necessary to specify the type for basic things like
> strings.
>
> --- Maxime Levesque <ma...@mail.mcgill.ca> wrote:
>>
>>   Ok, using oracle's number(9) type solved the casting problem
>> (number(10) or bigger causes a type cast exception, which is
>> reasoneable)
>>
>>  I still have the "strings become null",
>>
>>  interestingly number(9) (c# int types), and Date (c# DateTime)
>> get inserted correctly, so far, oracle varchar2 (c# strings)
>> are problematic (they are saved as null in the DB)...
>
>