SQL Batch execution failing for SysAdmin user

Having the strangest issue I've ever encountered. I have a batch of SQL statements to pull a chunk of data from SQL to a text file. The batch runs in our development, sandbox environments with no problem. In production, under the SQL agent service account, the batch fails on a simple select statement, but runs successfully for other users. Through trial and error, I confirmed the script fails on simple Select statement with the following error: > [Microsoft ODBC Driver 17 for SQL Server][SQL Server]The current transaction cannot be committed and cannot support operations that write to the log file. Roll back the transaction. (3930) (SQLExecDirectW) While debugging, I found the first query that the batch fails in. There are two statements that have a problem. Both are SELECTS that cross databases on the same server. I'll focus on the first one here for simplicity. This query does a select from a small table and pivots the data into a grid with text strings for TRUE or FALSE for 8 columns. Query is run in database #1, selecting data from database #2, from a table like this ( ignore the poor coding standards for this sample ): Selecting data from the following schema for

Database2.dbo.table1(
field1 uniqueidentifier not null Primary Key Clustered
, field2 datetime2(7) not null
, field3 varchar(50) not null
, field4 varchar(50) not null
, field5 varchar(50) not null
, field6 tinyint not null
, field7 tinyint not null
, field8 varchar(50) not null
, field9 varchar(50) not null
, field10 datetime not null
, field11 varchar(50) not null
, field12 datetime not null
, field12 uniqueidentifier not null

Table has about 4,200 rows, relatively static. no other indexes on the table.

SELECT 
   field4
   , cast(field5 as uniqueidentifier) as field2
   , isnull(max(case when field4 = 'x' AND field8 = 'a' then 'TRUE' else 'FALSE' end), 'FALSE') as ALabel
   , isnull(max(case when field4 = 'x' AND field8 = 'b' then 'TRUE' else 'FALSE' end), 'FALSE') as BLabel
   , isnull(max(case when field4 = 'x' AND field8 = 'c' then 'TRUE' else 'FALSE' end), 'FALSE') as CLabel
   , isnull(max(case when field4 = 'x' AND field8 = 'D' then 'TRUE' else 'FALSE' end), 'FALSE') as DLabel
   , isnull(max(case when field4 = 'x' AND field8 = 'E' then 'TRUE' else 'FALSE' end), 'FALSE') as ELabel
   , isnull(max(case when field4 = 'y' AND field8 = 'L' then 'TRUE' else 'FALSE' end), 'FALSE') as LLabel
   , isnull(max(case when field4 = 'y' AND field8 = 'M' then 'TRUE' else 'FALSE' end), 'FALSE') as MLabel
   , isnull(max(case when field4 = 'y' AND field8 = 'N' then 'TRUE' else 'FALSE' end), 'FALSE') as NLabel
FROM database2.dbo.Table1
WHERE 
FIELD8 not in ( 'J', 'K' )
and field4 in ( 'x','y' )
AND FIeld10 >= '2024-01-01'
GROUP BY 
   field4
   , cast(field5 as uniqueidentifier)

When I run the above select, I get less than 450 rows in the result, and takes less than 1 second. When the SQL Agent Service account runs the select cross database it get's the error. All runs are being done by a Python script reading the SQL batch in from a text file, and connecting to SQL server to execute. The SQL Agent runs the process with other scripts. Software versions match on all the servers, MS SQL Server 2017, current patches. DBAs assure me that service agent account has access to all the databases Securities for the service account match in all environments, sysadmin. All python software versions including libraries, match between environments, and my machine. Other environment factors: Both the Sandbox and Production servers are the primary of secondary group in a Distributed Availability Group. SQL databases have free space in files, and auto growth enabled so it shouldn't be a space issue, Driver might return false error if no space available. DBAs tell me there's no locks being held for long time on any of the tables Python script creates new connection for each batch run. No other SQL commands issued in the connection but the above select, and I get the error from the SQL agent. Problem consistently fails for service account and always works for users. My thoughts: Could there be a Server setting that causes cross database queries to behave differently in production? Could the fact it's the secondary in the DAG cause this? Could the DBAs be wrong about it being a security issue? Is there anything else I'm missing?