I migrated after this initial ticket to Jira 7.7.1 and this is no longer a concern – we haven't fully updated to 7.92, so I can't say if this is reoccuring or not.

Hello Team,

At present we are using Jira v7.3.6 and we are planning to upgrade directly from Jira v7.3.6 to Jira 7.9.2. As you mentioned above this problem is fixed in Jira v 7.6.3 then please let us know "Manually update all columns in table AO_E8B6CC_% from ntext to nvarchar(max)" Is this activity need to do while upgrading Jira v7.9.2??

Thanks! 

Fixed in version 7.6.3.

What is the resolution? How was this moved to resolved? We are still experiencing this issue and need guidance

This recommended workaround did not work for us. I'm now seeing the following in the logs. Has anyone else seen this follow-on issue? This is really impacting our production workflow.

The DELETE statement conflicted with the REFERENCE constraint "fk_ao_e8b6cc_message_queue_item_message_id". The conflict occurred in database "jira", table "jiraschema.AO_E8B6CC_MESSAGE_QUEUE_ITEM", column 'MESSAGE_ID'.

Will Atlassian support this change, if implemented.

I identified the tables to change with
select * from INFORMATION_SCHEMA.COLUMNS WHERE DATA_TYPE in ('TEXT', 'NTEXT')
and TABLE_NAME like 'AO_E8B6CC_%'

Which gives me:  
AO_E8B6CC_SYNC_EVENT
AO_E8B6CC_SYNC_EVENT
AO_E8B6CC_ISSUE_MAPPING_V2
AO_E8B6CC_ISSUE_MAPPING_V2
AO_E8B6CC_CHANGESET_MAPPING
AO_E8B6CC_CHANGESET_MAPPING
AO_E8B6CC_CHANGESET_MAPPING
AO_E8B6CC_REPOSITORY_MAPPING
AO_E8B6CC_SYNC_AUDIT_LOG
AO_E8B6CC_COMMIT

And this SQL will give me the correct alter statement preserving the nullability of a column.
select
'alter table [dbo].' + quotename(TABLE_NAME)
+ ' alter column ' + quotename(COLUMN_NAME)
+ ' nvarchar(max) '
+ case when IS_NULLABLE = 'NO' then 'not null' else 'null' end
+ ';'
from
INFORMATION_SCHEMA.COLUMNS
where
DATA_TYPE in ('NTEXT')
and TABLE_NAME like 'AO_E8B6CC_%'
Ideally, Atlassian will support these changes and let me get our critically needed GIT / JIRA integration functional again – our DEV process is currently severely impacted by this issue.

prunge I think that most probably this is caused by https://ecosystem.atlassian.net/browse/AO-3429

 https://bitbucket.org/activeobjects/ao/pull-requests/90/ao-3429-ao-3430-issue-jsds-307-nvarchar/diff

I did change to nvarchar(max) for all AO_E8B6CC_% and made collation to be same for them as well for other columns i DVCS tables.  GITHUB is now connected and works. Something like this can be used:

SELECT CONCAT( 'ALTER TABLE ' ,T.name, ' ALTER COLUMN ', C.name, ' nvarchar(max) COLLATE SQL_Latin1_General_CP437_CI_AI;') FROM   sys.tables AS T INNER JOIN sys.columns C ON T.object_id = C.object_id WHERE  collation_name IS NOT NULL AND collation_name = 'SQL_Latin1_General_CP437_CI_AI' AND T.name like 'AO_E8B6CC_%' and type_name(c.user_type_id) ='ntext'

or
ALTER TABLE AO_E8B6CC_MESSAGE ALTER COLUMN PAYLOAD NVARCHAR(MAX)

Using the SQL above on a MS SQL 2012 server if I cast the text column to a nvarchar(max) the SQL starts functioning again. (see below SQL). 

MS is removing support for text, ntext, and image datatypes. The Payload json object is a ntext column, while the other columns in this DB are varchar(255), seems like a solution to explore is migrating this column from ntext to text.

https://docs.microsoft.com/en-us/sql/t-sql/data-types/ntext-text-and-image-transact-sql

select "AO_E8B6CC_MESSAGE"."ID",
"AO_E8B6CC_MESSAGE"."ADDRESS",
CAST ("AO_E8B6CC_MESSAGE"."PAYLOAD" AS NVARCHAR(MAX)),
"AO_E8B6CC_MESSAGE"."PAYLOAD_TYPE",
"AO_E8B6CC_MESSAGE"."PRIORITY",
max("AO_E8B6CC_MESSAGE_QUEUE_ITEM"."RETRIES_COUNT") as "RETRIES_COUNT"
from "dbo"."AO_E8B6CC_MESSAGE" "AO_E8B6CC_MESSAGE"
left join "dbo"."AO_E8B6CC_MESSAGE_QUEUE_ITEM" "AO_E8B6CC_MESSAGE_QUEUE_ITEM"
on "AO_E8B6CC_MESSAGE"."ID" = "AO_E8B6CC_MESSAGE_QUEUE_ITEM"."MESSAGE_ID"
--where "AO_E8B6CC_MESSAGE"."ID" = ?
group by "AO_E8B6CC_MESSAGE"."ID",
"AO_E8B6CC_MESSAGE"."ADDRESS",
CAST ("AO_E8B6CC_MESSAGE"."PAYLOAD" AS NVARCHAR(MAX)) ,
"AO_E8B6CC_MESSAGE"."PAYLOAD_TYPE",
"AO_E8B6CC_MESSAGE"."PRIORITY"