Re: AseBulkCopy.WriteToServer fails when target is a non-nullable UDT

Hi Dave,

I did something to workaround the problem.  The root cause is the ASE type for the numeric UDT is 63 and there is no mapping for this to TDS_NUMN (the tds type for the column). When this happens the ADO.NET Provider code looks at the usertype.  For the 63 (numeric) this is 10 and code logic looks for this and sets type to TDS_NUMN.  However, the usertype = 103 (can be different on particular databases depending on how many user types are added and when this one was added in the mix) and this comes across, provider can't map to a TDS type and throws that exception.

All usertype fields in syscolumns seem to use this arbitrary value - but when I added a type of numeric: sp_addtype numnull, 'numeric(8,0)', null

create table target (c1 numnull null) the usertype is 10! Not its assigned UDT number. It works.

When I select from syscolumns:

select type, usertype from syscolumns where id = object_id('target')

the original returns 63 and 103.

With the table defined to allow null I get 108 and 10.

So I modified syscolumns:

sp_configure 'allow updates to system tables', 1
go

update syscolumns set usertype=10 where id=object_id('target')
go

-- BULK loads successfully

-- revert
update syscolumns set usertype=103 where id=object_id('target')
go

( I made sure I recorded the 103 - which is found in systypes table)

1> select name, type, usertype from systypes where name like 'num%'
2> go
name
                 type usertype
-----------------------------------------------------------------------------
---------------- ---- --------
numeric
                   63       10
numericn
                  108       28
numnull
                   63      106

(4 rows affected)
1> select name, type, usertype from systypes where name like 'typ%'
2> go
name
                 type usertype
-----------------------------------------------------------------------------
---------------- ---- --------
typ_small_id
                   63      103
typ_small_id_null
                   63      104

I don't know if changing this has repercussions, as a workaround, so if you do try it test thoroughly. I will proceed with logging the CR and escalate it. If you can , please create SAP Tech Support incident.

Cheers,

-Paul