I created the same 3 user-defined datatypes and then created 2 tables ... first time with the same user-defined datatypes, second time with the system data types:
=================
A - create table hts_ae_codes (ae_id id_t not null, ae_code shrt_name_t not null, ae_name comment_t not null) lock datarows
B - create table hts_ae_codes_2 (ae_id int not null, ae_code varchar(4) not null, ae_name varchar(21) not null) lock datarows
-- for both tables I created 2 rows:
insert hts_ae_codes values (1,'name1','comment1')
insert hts_ae_codes values (2,'name2','comment2')
=================
For both tables I ran a series of 4 select/into queries representing the 4 combinations of including/excluding the 'dbo.' prefix for the source and target tables:
=================
1 - select ae_id=ae_id , ae_code=ae_code , ae_name=ae_name into hts_ae_codes_HS from hts_ae_codes
2 - select ae_id=ae_id , ae_code=ae_code , ae_name=ae_name intodbo.hts_ae_codes_HS from dbo.hts_ae_codes
3 - select ae_id=ae_id , ae_code=ae_code , ae_name=ae_name into hts_ae_codes_HS from dbo.hts_ae_codes
4 - select ae_id=ae_id , ae_code=ae_code , ae_name=ae_name into dbo.hts_ae_codes_HS from hts_ae_codes
=================
Test results:
A.1 - table created/populated; no errors
A.2 - table created/populated; 'Msg 911' errors generated
A.3 - table created/populated; no errors
A.4 - table created/populated; 'Msg 911' errors generated
B.1 - table created/populated; no errors
B.2 - table created/populated; no errors
B.3 - table created/populated; no errors
B.4 - table created/populated; no errors
All tests successfully created and populated the table; the 2x tests that generated the 'Msg 911' errors were those where the target table included the 'dbo.' prefix and user-defined datatypes were involved.
NOTE: I got the same test results in ASE 15.0.3 ESD 4.1, and ASE 15.7 SP135.
----------------
At this point it looks like the DSI is submitting a valid SQL statement but there's a bug in ASE when a) the target of the 'select/into' includes the 'dbo.' prefix (just 'dbo' or any user?) and b) user-defined datatypes are involved.
Possible workarounds ...
- don't use user-defined datatypes in conjunction with replicated 'select/into' commands
- configure the DSI connection to ignore 'Msg 911' (could be problematic since 911 is a nasty error that could occur under other circumstances ... circumstances you really wouldn't want to ignore)
- just resume/skip these transactions and hope they don't happen very often
- add logic to your monitoring script to automatically issue a 'resume/skip' when this combo occurs: select/into + user-defined datatypes => generates 'Msg 911' errors