Skip to Main Content

ODP.NET

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

"Value does not fall within the expected range" when passing UDT to the stored procedure

JWuFeb 2 2020

Here's my class mapping to the UDT (really simple):

[OracleCustomTypeMapping("PORTAL_OPS.SHAPEUDT")]

public class Shape : IOracleCustomType, IOracleCustomTypeFactory

{

     [OracleObjectMapping("SIDES")]

     public Int32 Sides { get; set; }

     public string UdtTypeName

     {

          get

          {

               Attribute attr = Attribute.GetCustomAttribute(this.GetType()

                                        , typeof(OracleCustomTypeMappingAttribute));

               return (attr != null) ?

               ((OracleCustomTypeMappingAttribute)attr).UdtTypeName

                :

               String.Empty;

          }

     }

     public void FromCustomObject(OracleConnection con, IntPtr pUdt)

     {

          OracleUdt.SetValue(con, pUdt, "SIDES", Sides);

     }

     public void ToCustomObject(OracleConnection con, IntPtr pUdt)

     {

          Sides = (int)OracleUdt.GetValue(con, pUdt,"SIDES");

     }

     public IOracleCustomType CreateObject()

     {

          return new Shape();

     }

}

To call the stored procedure:

     if (Command.Connection.State == ConnectionState.Closed)

     {

          Command.Connection.Open();

     }

     // setting up the parameter

     OracleParameter param = new OracleParameter();

     param.Direction = ParameterDirection.Input;

     param.UdtTypeName = udt.UdtTypeName;

     param.DbType = DbType.Object;

     param.OracleDbType = OracleDbType.Object;

     param.Value = udt;

     Command.CommandText = "PORTAL_OPS.PROC_CREATE_SHAPE";

     Command.CommandType = CommandType.StoredProcedure;

     Command.Parameters.Add(param);

     Command.ExecuteNonQuery();

A couple of points:

  • Oracle's documentation says to use  OracleCustomTypeMappingAttribute, but I notice a lot of people use OracleCustomTypeMapping.  Which one is the correct one to use?
  • While I was troubleshooting, I purposely misspelled the the value inside the OracleObjectMapping...and it didn't seem to affect anything...still getting the "Value does not fail within the expected range"?

The stacktrace stopps at

OracleCustomTypeMappingAttribute.ctor(String udtTypeName)   (I am sure the UDT type name is correct)

Help!  Thanks!

Comments

kkovachki

This is a bug

Also there is update on the SRPMS

x86_64:

vdsm-4.20.46-1.0.8.el7.x86_64.rpm

vdsm-api-4.20.46-1.0.8.el7.noarch.rpm

vdsm-client-4.20.46-1.0.8.el7.noarch.rpm

vdsm-common-4.20.46-1.0.8.el7.noarch.rpm

vdsm-gluster-4.20.46-1.0.8.el7.x86_64.rpm

vdsm-hook-allocate_net-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-boot_hostdev-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-checkimages-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-checkips-4.20.46-1.0.8.el7.x86_64.rpm

vdsm-hook-cpuflags-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-diskunmap-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-ethtool-options-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-extnet-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-extra-ipv4-addrs-4.20.46-1.0.8.el7.x86_64.rpm

vdsm-hook-fakevmstats-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-faqemu-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-fcoe-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-fileinject-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-floppy-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-httpsisoboot-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-ipv6-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-isolatedprivatevlan-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-localdisk-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-macbind-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-macspoof-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-nestedvt-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-noipspoof-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-numa-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-openstacknet-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-pincpu-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-promisc-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-qemucmdline-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-qos-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-scratchpad-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-smbios-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-spiceoptions-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-vhostmd-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-vmdisk-4.20.46-1.0.8.el7.noarch.rpm

vdsm-hook-vmfex-dev-4.20.46-1.0.8.el7.noarch.rpm

vdsm-http-4.20.46-1.0.8.el7.noarch.rpm

vdsm-jsonrpc-4.20.46-1.0.8.el7.noarch.rpm

vdsm-network-4.20.46-1.0.8.el7.x86_64.rpm

vdsm-python-4.20.46-1.0.8.el7.noarch.rpm

vdsm-tests-4.20.46-1.0.8.el7.noarch.rpm

vdsm-yajsonrpc-4.20.46-1.0.8.el7.noarch.rpm

http://oss.oracle.com/ol7/SRPMS-updates/

Bug

https://linux.oracle.com/errata/ELBA-2019-4765.html

The workaround is as follows:

# yum install yum-plugin-versionlock

# yum versionlock sos

# yum update -y

The latest vdsm package (vdsm-4.20.46-1.0.8.el7.x86_64) is having fix for this issue.

Note : sos package has to be downgraded (with "yum downgrade sos") until the release sos-3.6*.

issue is sos-3.7 is not accepted by vdsm, downgrade is needed until the release sos-3.6* is available on system.

# rpm -q --requires vdsm | grep sos

sos < 3.7

Ian Hoogeboom

The latest vdsm package (vdsm-4.20.46-1.0.8.el7.x86_64) is having fix for this issue.

The latest version 'vdsm-4.20.46-1.0.8.el7.x86_64' is still having the issue:

Error: sos conflicts with vdsm-4.20.46-1.0.8.el7.x86_64

Error: Package: vdsm-4.20.46-1.0.8.el7.x86_64 (@ovirt-4.2)

           Requires: sos < 3.7

Simon Coter-Oracle

Best option to get this issue sorted out is now to upgrade to OLVM 4.3 release.

1 - 5

Post Details

Added on Feb 2 2020
0 comments
2,740 views