Microsoft Dotnet, Timestamp, and Char <very odd>

  • Thread starter Thread starter Tracy Fletcher
  • Start date Start date
T

Tracy Fletcher

Hi there,

I am calling a number of Oracle stored procedures via the Microsoft
OracleClient and the ODP.Net client (Using OracleDataAdapter.Update
and/or Direct OracleCommand.ExecuteNonQuery in both) and I am noticing
that any char parameters are over-padded with a full set (eg. 5 for
char(5)) of blank characters (even when no padding is necessary or in
addition to correct padding) whenever they are located after a
timestamp parameter. This, of course, causes an 'Inserted value too
large' error on those overpadded columns. The timestamp parameter has
a null default, and causes no problems if the parameter is not passed
and the default applied. However, if the parameter is passed with a
actual value or DBNull.Value then the error occurs.

Has anyone experienced anything like this? We are faced with making
sure timestamp parameters are always at the bottom of the parameter
list or using varchars for all logically fixed string columns.
Neither really addresses the root problem.

Thanks,

Tracy Fletcher
 
On 3 Feb 2004 14:12:28 -0800, (e-mail address removed) (Tracy Fletcher) wrote:

¤ Hi there,
¤
¤ I am calling a number of Oracle stored procedures via the Microsoft
¤ OracleClient and the ODP.Net client (Using OracleDataAdapter.Update
¤ and/or Direct OracleCommand.ExecuteNonQuery in both) and I am noticing
¤ that any char parameters are over-padded with a full set (eg. 5 for
¤ char(5)) of blank characters (even when no padding is necessary or in
¤ addition to correct padding) whenever they are located after a
¤ timestamp parameter. This, of course, causes an 'Inserted value too
¤ large' error on those overpadded columns. The timestamp parameter has
¤ a null default, and causes no problems if the parameter is not passed
¤ and the default applied. However, if the parameter is passed with a
¤ actual value or DBNull.Value then the error occurs.
¤
¤ Has anyone experienced anything like this? We are faced with making
¤ sure timestamp parameters are always at the bottom of the parameter
¤ list or using varchars for all logically fixed string columns.
¤ Neither really addresses the root problem.

I think the problem is that you're using a fixed length parameter to hold a unicode (two character
per byte) string. A field type of varchar2 would probably be more appropriate to use.


Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)
 
Back
Top