tSQLt on SQL Server 2017 AG with DTC enabled
up vote
2
down vote
favorite
I receive the following error when I am running tSQLt tests on SQL Server 2017 that is setup in an Always On availability group that is configured with DTC_SUPPORT = PER_DB on the AG group. If I turn off the DTC Support, it works fine. Our environment requires DTC. Is there a way to work around this in tSQLt or is there a different way to configure SQL so that both DTC and tSQLt will work?
Here is the error:
Test Procedure: [xxx].[zzfnCipValidateCustomerAddress].[test '12345' Zip Codes] on DbServer
[zzfnCipValidateCustomerAddress].[test '12345' Zip Codes] failed: (Error) Cannot promote the transaction to a distributed transaction because there is an active save point in this transaction.[16,1]{zzfnCipValidateCustomerAddress.test '12345' Zip Codes,36} (There was also a ROLLBACK ERROR --> The current transaction cannot be committed and cannot be rolled back to a savepoint. Roll back the entire transaction.{tSQLt.Private_RunTest,160})
Here is one of the failing tests:
CREATE PROCEDURE [zzfnCipValidateCustomerAddress].[test '12345' Zip Codes]
AS
BEGIN
--Assemble
/*
Test to determine if function is an Inline Table Valued function or not
since this function is being rewritten to be an ITVF function and this test should
pass both versions
*/
DECLARE @IsITVF BIT;
SELECT @IsITVF = IIF(fc.FunctionCount > 0, 1, 0)
FROM
(
SELECT COUNT(*) AS FunctionCount
FROM sys.sql_modules AS sm
JOIN sys.objects AS o
ON sm.object_id = o.object_id
WHERE sm.object_id = OBJECT_ID('dbo.fnCipValidateCustomerAddress')
AND o.type = 'IF' --'IF' = Inline Valued Table Function
) AS fc;
SELECT @IsITVF;
--DROP TABLE IF EXISTS zzfnCipValidateCustomerAddress.TestData;
CREATE TABLE zzfnCipValidateCustomerAddress.TestData
(
AddressLine1 VARCHAR(100),
AddressLine2 VARCHAR(100),
City VARCHAR(50),
StateAbbr VARCHAR(3),
ZipCode VARCHAR(9)
);
INSERT INTO zzfnCipValidateCustomerAddress.TestData
(
AddressLine1,
AddressLine2,
City,
StateAbbr,
ZipCode
)
VALUES
('Test', NULL, 'Test', 'AZ', '12345');
CREATE TABLE zzfnCipValidateCustomerAddress.Expected
(
AddressLine1 VARCHAR(100),
AddressLine2 VARCHAR(100),
City VARCHAR(50),
StateAbbr VARCHAR(3),
ZipCode VARCHAR(9),
CipExceptionReasonId INT
);
INSERT INTO zzfnCipValidateCustomerAddress.Expected
(
AddressLine1,
AddressLine2,
City,
StateAbbr,
ZipCode,
CipExceptionReasonId
)
VALUES
('Test', NULL, 'Test', 'AZ', '12345', 8);
--Act
IF (@IsITVF = 0)
BEGIN
SELECT td.AddressLine1,
td.AddressLine2,
td.City,
td.StateAbbr,
td.ZipCode,
dbo.fnCipValidateCustomerAddress(td.AddressLine1, td.AddressLine2, td.City, td.StateAbbr, td.ZipCode) AS CipExceptionReasonId
INTO zzfnCipValidateCustomerAddress.Actual
FROM zzfnCipValidateCustomerAddress.TestData AS td;
END;
ELSE
BEGIN
SELECT fcvcat.AddressLine1,
fcvcat.AddressLine2,
fcvcat.City,
fcvcat.StateAbbr,
fcvcat.ZipCode,
fcvcat.CipExceptionReasonId
INTO zzfnCipValidateCustomerAddress.Actual
FROM zzfnCipValidateCustomerAddress.TestData AS td
CROSS APPLY dbo.fnCipValidateCustomerAddress(
td.AddressLine1,
td.AddressLine2,
td.City,
td.StateAbbr,
td.ZipCode
) AS fcvcat;
END;
--Assert
EXEC tSQLt.AssertEqualsTable @Expected = N'zzfnCipValidateCustomerAddress.Expected',
@Actual = N'zzfnCipValidateCustomerAddress.Actual',
@Message = N'',
@FailMsg = N'Zip with value of ''12345'' did not generate a CipExceptionReasonId as expected';
END;
sql-server alwayson tsqlt
add a comment |
up vote
2
down vote
favorite
I receive the following error when I am running tSQLt tests on SQL Server 2017 that is setup in an Always On availability group that is configured with DTC_SUPPORT = PER_DB on the AG group. If I turn off the DTC Support, it works fine. Our environment requires DTC. Is there a way to work around this in tSQLt or is there a different way to configure SQL so that both DTC and tSQLt will work?
Here is the error:
Test Procedure: [xxx].[zzfnCipValidateCustomerAddress].[test '12345' Zip Codes] on DbServer
[zzfnCipValidateCustomerAddress].[test '12345' Zip Codes] failed: (Error) Cannot promote the transaction to a distributed transaction because there is an active save point in this transaction.[16,1]{zzfnCipValidateCustomerAddress.test '12345' Zip Codes,36} (There was also a ROLLBACK ERROR --> The current transaction cannot be committed and cannot be rolled back to a savepoint. Roll back the entire transaction.{tSQLt.Private_RunTest,160})
Here is one of the failing tests:
CREATE PROCEDURE [zzfnCipValidateCustomerAddress].[test '12345' Zip Codes]
AS
BEGIN
--Assemble
/*
Test to determine if function is an Inline Table Valued function or not
since this function is being rewritten to be an ITVF function and this test should
pass both versions
*/
DECLARE @IsITVF BIT;
SELECT @IsITVF = IIF(fc.FunctionCount > 0, 1, 0)
FROM
(
SELECT COUNT(*) AS FunctionCount
FROM sys.sql_modules AS sm
JOIN sys.objects AS o
ON sm.object_id = o.object_id
WHERE sm.object_id = OBJECT_ID('dbo.fnCipValidateCustomerAddress')
AND o.type = 'IF' --'IF' = Inline Valued Table Function
) AS fc;
SELECT @IsITVF;
--DROP TABLE IF EXISTS zzfnCipValidateCustomerAddress.TestData;
CREATE TABLE zzfnCipValidateCustomerAddress.TestData
(
AddressLine1 VARCHAR(100),
AddressLine2 VARCHAR(100),
City VARCHAR(50),
StateAbbr VARCHAR(3),
ZipCode VARCHAR(9)
);
INSERT INTO zzfnCipValidateCustomerAddress.TestData
(
AddressLine1,
AddressLine2,
City,
StateAbbr,
ZipCode
)
VALUES
('Test', NULL, 'Test', 'AZ', '12345');
CREATE TABLE zzfnCipValidateCustomerAddress.Expected
(
AddressLine1 VARCHAR(100),
AddressLine2 VARCHAR(100),
City VARCHAR(50),
StateAbbr VARCHAR(3),
ZipCode VARCHAR(9),
CipExceptionReasonId INT
);
INSERT INTO zzfnCipValidateCustomerAddress.Expected
(
AddressLine1,
AddressLine2,
City,
StateAbbr,
ZipCode,
CipExceptionReasonId
)
VALUES
('Test', NULL, 'Test', 'AZ', '12345', 8);
--Act
IF (@IsITVF = 0)
BEGIN
SELECT td.AddressLine1,
td.AddressLine2,
td.City,
td.StateAbbr,
td.ZipCode,
dbo.fnCipValidateCustomerAddress(td.AddressLine1, td.AddressLine2, td.City, td.StateAbbr, td.ZipCode) AS CipExceptionReasonId
INTO zzfnCipValidateCustomerAddress.Actual
FROM zzfnCipValidateCustomerAddress.TestData AS td;
END;
ELSE
BEGIN
SELECT fcvcat.AddressLine1,
fcvcat.AddressLine2,
fcvcat.City,
fcvcat.StateAbbr,
fcvcat.ZipCode,
fcvcat.CipExceptionReasonId
INTO zzfnCipValidateCustomerAddress.Actual
FROM zzfnCipValidateCustomerAddress.TestData AS td
CROSS APPLY dbo.fnCipValidateCustomerAddress(
td.AddressLine1,
td.AddressLine2,
td.City,
td.StateAbbr,
td.ZipCode
) AS fcvcat;
END;
--Assert
EXEC tSQLt.AssertEqualsTable @Expected = N'zzfnCipValidateCustomerAddress.Expected',
@Actual = N'zzfnCipValidateCustomerAddress.Actual',
@Message = N'',
@FailMsg = N'Zip with value of ''12345'' did not generate a CipExceptionReasonId as expected';
END;
sql-server alwayson tsqlt
I'd need a lot more information than this to even start troubleshooting. Starting with, what does the failing test look like. Is there one particular statement that fails? Does the test involve any form of transaction management? - Or is every test failing in that environment?
– Sebastian Meine
Nov 20 at 14:30
I added in an example of a test that is failing as requested. I am not using any transaction management in the tests. Also, all tests are failing. The function being tested is a table valued function that also is a table valued function and does not involve any transaction management. If there is any other information you need please let me know.
– silverbullettruck2001
Nov 20 at 15:46
So, what I don't understand is why you are in an environment with always-on enabled. Tests (and in particular tSQLt) should never be run in production. Can you tell me more about your setup?
– Sebastian Meine
Nov 20 at 17:41
@sebastian-meine Our DBAs use our development environment as their "development" area as well, so they setup all functionality that they want to implement in production environment to our development environment first and then promote those features. This allows them to verify that their AlwaysOn configurations work in Dev first and they can verify that it won't break when they implement it in UAT and Production. They do the same thing for other features/configurations as well. The objective is to has as few differences between each of our environments.
– silverbullettruck2001
Nov 20 at 19:18
If you create an empty test (one that contains just a RETURN statement), and then execute just that test, do you still get the same error?
– Sebastian Meine
Nov 21 at 11:32
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I receive the following error when I am running tSQLt tests on SQL Server 2017 that is setup in an Always On availability group that is configured with DTC_SUPPORT = PER_DB on the AG group. If I turn off the DTC Support, it works fine. Our environment requires DTC. Is there a way to work around this in tSQLt or is there a different way to configure SQL so that both DTC and tSQLt will work?
Here is the error:
Test Procedure: [xxx].[zzfnCipValidateCustomerAddress].[test '12345' Zip Codes] on DbServer
[zzfnCipValidateCustomerAddress].[test '12345' Zip Codes] failed: (Error) Cannot promote the transaction to a distributed transaction because there is an active save point in this transaction.[16,1]{zzfnCipValidateCustomerAddress.test '12345' Zip Codes,36} (There was also a ROLLBACK ERROR --> The current transaction cannot be committed and cannot be rolled back to a savepoint. Roll back the entire transaction.{tSQLt.Private_RunTest,160})
Here is one of the failing tests:
CREATE PROCEDURE [zzfnCipValidateCustomerAddress].[test '12345' Zip Codes]
AS
BEGIN
--Assemble
/*
Test to determine if function is an Inline Table Valued function or not
since this function is being rewritten to be an ITVF function and this test should
pass both versions
*/
DECLARE @IsITVF BIT;
SELECT @IsITVF = IIF(fc.FunctionCount > 0, 1, 0)
FROM
(
SELECT COUNT(*) AS FunctionCount
FROM sys.sql_modules AS sm
JOIN sys.objects AS o
ON sm.object_id = o.object_id
WHERE sm.object_id = OBJECT_ID('dbo.fnCipValidateCustomerAddress')
AND o.type = 'IF' --'IF' = Inline Valued Table Function
) AS fc;
SELECT @IsITVF;
--DROP TABLE IF EXISTS zzfnCipValidateCustomerAddress.TestData;
CREATE TABLE zzfnCipValidateCustomerAddress.TestData
(
AddressLine1 VARCHAR(100),
AddressLine2 VARCHAR(100),
City VARCHAR(50),
StateAbbr VARCHAR(3),
ZipCode VARCHAR(9)
);
INSERT INTO zzfnCipValidateCustomerAddress.TestData
(
AddressLine1,
AddressLine2,
City,
StateAbbr,
ZipCode
)
VALUES
('Test', NULL, 'Test', 'AZ', '12345');
CREATE TABLE zzfnCipValidateCustomerAddress.Expected
(
AddressLine1 VARCHAR(100),
AddressLine2 VARCHAR(100),
City VARCHAR(50),
StateAbbr VARCHAR(3),
ZipCode VARCHAR(9),
CipExceptionReasonId INT
);
INSERT INTO zzfnCipValidateCustomerAddress.Expected
(
AddressLine1,
AddressLine2,
City,
StateAbbr,
ZipCode,
CipExceptionReasonId
)
VALUES
('Test', NULL, 'Test', 'AZ', '12345', 8);
--Act
IF (@IsITVF = 0)
BEGIN
SELECT td.AddressLine1,
td.AddressLine2,
td.City,
td.StateAbbr,
td.ZipCode,
dbo.fnCipValidateCustomerAddress(td.AddressLine1, td.AddressLine2, td.City, td.StateAbbr, td.ZipCode) AS CipExceptionReasonId
INTO zzfnCipValidateCustomerAddress.Actual
FROM zzfnCipValidateCustomerAddress.TestData AS td;
END;
ELSE
BEGIN
SELECT fcvcat.AddressLine1,
fcvcat.AddressLine2,
fcvcat.City,
fcvcat.StateAbbr,
fcvcat.ZipCode,
fcvcat.CipExceptionReasonId
INTO zzfnCipValidateCustomerAddress.Actual
FROM zzfnCipValidateCustomerAddress.TestData AS td
CROSS APPLY dbo.fnCipValidateCustomerAddress(
td.AddressLine1,
td.AddressLine2,
td.City,
td.StateAbbr,
td.ZipCode
) AS fcvcat;
END;
--Assert
EXEC tSQLt.AssertEqualsTable @Expected = N'zzfnCipValidateCustomerAddress.Expected',
@Actual = N'zzfnCipValidateCustomerAddress.Actual',
@Message = N'',
@FailMsg = N'Zip with value of ''12345'' did not generate a CipExceptionReasonId as expected';
END;
sql-server alwayson tsqlt
I receive the following error when I am running tSQLt tests on SQL Server 2017 that is setup in an Always On availability group that is configured with DTC_SUPPORT = PER_DB on the AG group. If I turn off the DTC Support, it works fine. Our environment requires DTC. Is there a way to work around this in tSQLt or is there a different way to configure SQL so that both DTC and tSQLt will work?
Here is the error:
Test Procedure: [xxx].[zzfnCipValidateCustomerAddress].[test '12345' Zip Codes] on DbServer
[zzfnCipValidateCustomerAddress].[test '12345' Zip Codes] failed: (Error) Cannot promote the transaction to a distributed transaction because there is an active save point in this transaction.[16,1]{zzfnCipValidateCustomerAddress.test '12345' Zip Codes,36} (There was also a ROLLBACK ERROR --> The current transaction cannot be committed and cannot be rolled back to a savepoint. Roll back the entire transaction.{tSQLt.Private_RunTest,160})
Here is one of the failing tests:
CREATE PROCEDURE [zzfnCipValidateCustomerAddress].[test '12345' Zip Codes]
AS
BEGIN
--Assemble
/*
Test to determine if function is an Inline Table Valued function or not
since this function is being rewritten to be an ITVF function and this test should
pass both versions
*/
DECLARE @IsITVF BIT;
SELECT @IsITVF = IIF(fc.FunctionCount > 0, 1, 0)
FROM
(
SELECT COUNT(*) AS FunctionCount
FROM sys.sql_modules AS sm
JOIN sys.objects AS o
ON sm.object_id = o.object_id
WHERE sm.object_id = OBJECT_ID('dbo.fnCipValidateCustomerAddress')
AND o.type = 'IF' --'IF' = Inline Valued Table Function
) AS fc;
SELECT @IsITVF;
--DROP TABLE IF EXISTS zzfnCipValidateCustomerAddress.TestData;
CREATE TABLE zzfnCipValidateCustomerAddress.TestData
(
AddressLine1 VARCHAR(100),
AddressLine2 VARCHAR(100),
City VARCHAR(50),
StateAbbr VARCHAR(3),
ZipCode VARCHAR(9)
);
INSERT INTO zzfnCipValidateCustomerAddress.TestData
(
AddressLine1,
AddressLine2,
City,
StateAbbr,
ZipCode
)
VALUES
('Test', NULL, 'Test', 'AZ', '12345');
CREATE TABLE zzfnCipValidateCustomerAddress.Expected
(
AddressLine1 VARCHAR(100),
AddressLine2 VARCHAR(100),
City VARCHAR(50),
StateAbbr VARCHAR(3),
ZipCode VARCHAR(9),
CipExceptionReasonId INT
);
INSERT INTO zzfnCipValidateCustomerAddress.Expected
(
AddressLine1,
AddressLine2,
City,
StateAbbr,
ZipCode,
CipExceptionReasonId
)
VALUES
('Test', NULL, 'Test', 'AZ', '12345', 8);
--Act
IF (@IsITVF = 0)
BEGIN
SELECT td.AddressLine1,
td.AddressLine2,
td.City,
td.StateAbbr,
td.ZipCode,
dbo.fnCipValidateCustomerAddress(td.AddressLine1, td.AddressLine2, td.City, td.StateAbbr, td.ZipCode) AS CipExceptionReasonId
INTO zzfnCipValidateCustomerAddress.Actual
FROM zzfnCipValidateCustomerAddress.TestData AS td;
END;
ELSE
BEGIN
SELECT fcvcat.AddressLine1,
fcvcat.AddressLine2,
fcvcat.City,
fcvcat.StateAbbr,
fcvcat.ZipCode,
fcvcat.CipExceptionReasonId
INTO zzfnCipValidateCustomerAddress.Actual
FROM zzfnCipValidateCustomerAddress.TestData AS td
CROSS APPLY dbo.fnCipValidateCustomerAddress(
td.AddressLine1,
td.AddressLine2,
td.City,
td.StateAbbr,
td.ZipCode
) AS fcvcat;
END;
--Assert
EXEC tSQLt.AssertEqualsTable @Expected = N'zzfnCipValidateCustomerAddress.Expected',
@Actual = N'zzfnCipValidateCustomerAddress.Actual',
@Message = N'',
@FailMsg = N'Zip with value of ''12345'' did not generate a CipExceptionReasonId as expected';
END;
sql-server alwayson tsqlt
sql-server alwayson tsqlt
edited Nov 20 at 15:40
asked Nov 19 at 15:21
silverbullettruck2001
1817
1817
I'd need a lot more information than this to even start troubleshooting. Starting with, what does the failing test look like. Is there one particular statement that fails? Does the test involve any form of transaction management? - Or is every test failing in that environment?
– Sebastian Meine
Nov 20 at 14:30
I added in an example of a test that is failing as requested. I am not using any transaction management in the tests. Also, all tests are failing. The function being tested is a table valued function that also is a table valued function and does not involve any transaction management. If there is any other information you need please let me know.
– silverbullettruck2001
Nov 20 at 15:46
So, what I don't understand is why you are in an environment with always-on enabled. Tests (and in particular tSQLt) should never be run in production. Can you tell me more about your setup?
– Sebastian Meine
Nov 20 at 17:41
@sebastian-meine Our DBAs use our development environment as their "development" area as well, so they setup all functionality that they want to implement in production environment to our development environment first and then promote those features. This allows them to verify that their AlwaysOn configurations work in Dev first and they can verify that it won't break when they implement it in UAT and Production. They do the same thing for other features/configurations as well. The objective is to has as few differences between each of our environments.
– silverbullettruck2001
Nov 20 at 19:18
If you create an empty test (one that contains just a RETURN statement), and then execute just that test, do you still get the same error?
– Sebastian Meine
Nov 21 at 11:32
add a comment |
I'd need a lot more information than this to even start troubleshooting. Starting with, what does the failing test look like. Is there one particular statement that fails? Does the test involve any form of transaction management? - Or is every test failing in that environment?
– Sebastian Meine
Nov 20 at 14:30
I added in an example of a test that is failing as requested. I am not using any transaction management in the tests. Also, all tests are failing. The function being tested is a table valued function that also is a table valued function and does not involve any transaction management. If there is any other information you need please let me know.
– silverbullettruck2001
Nov 20 at 15:46
So, what I don't understand is why you are in an environment with always-on enabled. Tests (and in particular tSQLt) should never be run in production. Can you tell me more about your setup?
– Sebastian Meine
Nov 20 at 17:41
@sebastian-meine Our DBAs use our development environment as their "development" area as well, so they setup all functionality that they want to implement in production environment to our development environment first and then promote those features. This allows them to verify that their AlwaysOn configurations work in Dev first and they can verify that it won't break when they implement it in UAT and Production. They do the same thing for other features/configurations as well. The objective is to has as few differences between each of our environments.
– silverbullettruck2001
Nov 20 at 19:18
If you create an empty test (one that contains just a RETURN statement), and then execute just that test, do you still get the same error?
– Sebastian Meine
Nov 21 at 11:32
I'd need a lot more information than this to even start troubleshooting. Starting with, what does the failing test look like. Is there one particular statement that fails? Does the test involve any form of transaction management? - Or is every test failing in that environment?
– Sebastian Meine
Nov 20 at 14:30
I'd need a lot more information than this to even start troubleshooting. Starting with, what does the failing test look like. Is there one particular statement that fails? Does the test involve any form of transaction management? - Or is every test failing in that environment?
– Sebastian Meine
Nov 20 at 14:30
I added in an example of a test that is failing as requested. I am not using any transaction management in the tests. Also, all tests are failing. The function being tested is a table valued function that also is a table valued function and does not involve any transaction management. If there is any other information you need please let me know.
– silverbullettruck2001
Nov 20 at 15:46
I added in an example of a test that is failing as requested. I am not using any transaction management in the tests. Also, all tests are failing. The function being tested is a table valued function that also is a table valued function and does not involve any transaction management. If there is any other information you need please let me know.
– silverbullettruck2001
Nov 20 at 15:46
So, what I don't understand is why you are in an environment with always-on enabled. Tests (and in particular tSQLt) should never be run in production. Can you tell me more about your setup?
– Sebastian Meine
Nov 20 at 17:41
So, what I don't understand is why you are in an environment with always-on enabled. Tests (and in particular tSQLt) should never be run in production. Can you tell me more about your setup?
– Sebastian Meine
Nov 20 at 17:41
@sebastian-meine Our DBAs use our development environment as their "development" area as well, so they setup all functionality that they want to implement in production environment to our development environment first and then promote those features. This allows them to verify that their AlwaysOn configurations work in Dev first and they can verify that it won't break when they implement it in UAT and Production. They do the same thing for other features/configurations as well. The objective is to has as few differences between each of our environments.
– silverbullettruck2001
Nov 20 at 19:18
@sebastian-meine Our DBAs use our development environment as their "development" area as well, so they setup all functionality that they want to implement in production environment to our development environment first and then promote those features. This allows them to verify that their AlwaysOn configurations work in Dev first and they can verify that it won't break when they implement it in UAT and Production. They do the same thing for other features/configurations as well. The objective is to has as few differences between each of our environments.
– silverbullettruck2001
Nov 20 at 19:18
If you create an empty test (one that contains just a RETURN statement), and then execute just that test, do you still get the same error?
– Sebastian Meine
Nov 21 at 11:32
If you create an empty test (one that contains just a RETURN statement), and then execute just that test, do you still get the same error?
– Sebastian Meine
Nov 21 at 11:32
add a comment |
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53377715%2ftsqlt-on-sql-server-2017-ag-with-dtc-enabled%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I'd need a lot more information than this to even start troubleshooting. Starting with, what does the failing test look like. Is there one particular statement that fails? Does the test involve any form of transaction management? - Or is every test failing in that environment?
– Sebastian Meine
Nov 20 at 14:30
I added in an example of a test that is failing as requested. I am not using any transaction management in the tests. Also, all tests are failing. The function being tested is a table valued function that also is a table valued function and does not involve any transaction management. If there is any other information you need please let me know.
– silverbullettruck2001
Nov 20 at 15:46
So, what I don't understand is why you are in an environment with always-on enabled. Tests (and in particular tSQLt) should never be run in production. Can you tell me more about your setup?
– Sebastian Meine
Nov 20 at 17:41
@sebastian-meine Our DBAs use our development environment as their "development" area as well, so they setup all functionality that they want to implement in production environment to our development environment first and then promote those features. This allows them to verify that their AlwaysOn configurations work in Dev first and they can verify that it won't break when they implement it in UAT and Production. They do the same thing for other features/configurations as well. The objective is to has as few differences between each of our environments.
– silverbullettruck2001
Nov 20 at 19:18
If you create an empty test (one that contains just a RETURN statement), and then execute just that test, do you still get the same error?
– Sebastian Meine
Nov 21 at 11:32