问题:
尝试调用打包的存储过程,但调用失败取决于参数的值.
尝试调用打包的存储过程,但调用失败取决于参数的值.
ORA-06502: PL/sql: numeric or value error ORA-06512: at line 1
程序定义:
procedure DUP_EXACT ( SSN in VARCHAR2,LASTNAME in VARCHAR2,FIRSTNAME in VARCHAR2,MASTERRECORD IN VARCHAR2 DEFAULT NULL,C_Table out sp_cursor)
参数创建:
For Each SearchParameter In SearchParameters ValueParameter = New OracleParameter ValueParameter.Direction = ParameterDirection.Input ValueParameter.OracleDbType = OracleDbType.Varchar2 ValueParameter.ParameterName = SearchParameter.ParameterFieldName If Not SearchParameter.TransformedFieldValue = Nothing Then ValueParameter.Value = SearchParameter.TransformedFieldValue Else ValueParameter.Value = String.Empty End If ExactMatchSearchParameters.Add(ValueParameter) Next Dim MasterRecordParameter As New OracleParameter() MasterRecordParameter.Direction = ParameterDirection.Input MasterRecordParameter.OracleDbType = OracleDbType.Varchar2 MasterRecordParameter.ParameterName = "MASTERRECORD" MasterRecordParameter.Value = DBNull.Value ExactMatchSearchParameters.Add(MasterRecordParameter) Dim TableParameter As New OracleParameter TableParameter.ParameterName = "C_Table" TableParameter.OracleDbType = OracleDbType.RefCursor TableParameter.Direction = ParameterDirection.Output ExactMatchSearchParameters.Add(TableParameter)
执行:
Using Command As OracleCommand = New OracleCommand( QualifiedProcedureName,Me.Database.Connection) Command.CommandType = CommandType.StoredProcedure 'Command.AddToStatementCache = False ' For Each Parameter In Parameters Command.Parameters.Add(Parameter) Next Command.Connection.Open() 'Command.Connection.FlushCache() ' Using Reader As OracleDataReader = Command.ExecuteReader()
示例成功&失败:
*** SUCCESS *** [SSN]: "6#######0" [LASTNAME]: "W_____x" [FIRSTNAME]: "D______e" [MASTERRECORD]: "" [C_Table]: "" *** FAILURE *** [SSN]: "2#######_1" [LASTNAME]: "C____n" [FIRSTNAME]: "L___e" [MASTERRECORD]: "" [C_Table]: "" *** FAILURE *** [SSN]: "5#######5" [LASTNAME]: "C_______s" [FIRSTNAME]: "R_____o" [MASTERRECORD]: "" [C_Table]: "" *** SUCCESS *** [SSN]: "6#######0" [LASTNAME]: "P___a" [FIRSTNAME]: "N______r" [MASTERRECORD]: "" [C_Table]: ""
附加测试:
我试着运行跟踪来查看ODP.NET实际上在参数中发送到数据库的内容,但是tracefiles没有提供任何有意义的信息(IE:实际参数值)
TIME:2013/02/14-14:10:19:678 TID:231c OpssqlPrepare2(): sql: Begin PACKAGE.DUP_EXACT(:v0,:v1,:v2,:v3,:v4); End;
示例参数值:
?Command.Parameters(0) {SSN} ArrayBindSize: Nothing ArrayBindStatus: Nothing CollectionType: None {0} DbType: String {16} Direction: Input {1} InvalidPrecision: 100 InvalidScale: 129 InvalidSize: -1 IsNullable: False m_bOracleDbTypeExSet: False m_bReturnDateTimeOffset: False m_collRef: {Oracle.DataAccess.Client.OracleParameterCollection} m_commandText: "" m_direction: Input {1} m_disposed: False m_enumType: ORADBTYPE {4} m_modified: False m_oraDbType: Varchar2 {126} m_paramName: "SSN" m_paramPosOrName: "" m_saveValue: Nothing MaxScale: 127 MinScale: -84 Offset: 0 OracleDbType: Varchar2 {126} OracleDbTypeEx: Varchar2 {126} ParameterEnumType: ORADBTYPE {4} ParameterName: "SSN" Precision: 0 Scale: 0 Size: 0 SourceColumn: "" SourceColumnNullMapping: False SourceVersion: Current {512} Status: Success {0} UdtTypeName: "" Value: "4#######0" {String}
解决方法
答案是Oracle 9.2.0.6.0中存在一个导致间歇性VARCHAR2绑定错误的错误.真棒.
This forum post finally gave me the answer:
Is this behavior consistent or intermittent? If intermitten,and
your db is 9206,you’re likely encountering the following rdbms bug:Bug.4015165 (74) REGRN SCALAR VARCHAR2 IN BINDS WITH DIFFERENT SIZE
RANDOMLY FAILS WITH ORA-06502and should be resolved by patching your database.
I’m not sure why,but ODP seems to encounter this bug a lot more than
other drivers.If not intermittent,or if you are using a current patch level of
database,a complete testcase would probably be best.Cheers,
Greg
快速检查确认我们所使用的版本受到影响:
select * from v$version; ---------------------------------------------------------------- Oracle9i Enterprise Edition Release 9.2.0.6.0 - Production PL/sql Release 9.2.0.6.0 - Production CORE 9.2.0.6.0 Production TNS for 32-bit Windows: Version 9.2.0.6.0 - Production NLSRTL Version 9.2.0.6.0 - Production
幸运的是我们的生产服务器是10g,所以我们最终将我们的开发服务器更新到10g,而中提琴,没有更多的问题.
回答路径: