Current Security Context Not Trusted When Using Linked Server From ABAP

Question

Hello,
I am experiencing a head-scratcher of a problem when trying to use a Linked Server connection to query a remote SQL Server database from our R/3 system.  We have had this working just fine for some time, but after migrating to new hardware and upgrading OS, DBMS, and R/3, now we are running into problems.
The target database is a named instance on SQL Server 2000 SP3, Windows 2000 Server.  The original source R/3 system was 4.7x2.00, also on SQL Server 2000 (SP4), Windows 2000 Server.  I had been using a Linked Server defined via SQL Enterprise Manager (actually defined when the source was on SQL Server 7), which called an alias defined with the Client Network Utility that pointed to the remote named instance.  This alias and Linked Server worked great for several years.
Now we have migrated our R/3 system onto new hardware, running Windows Server 2003 SP1 and SQL Server 2005 SP1.  The application itself has been upgraded to ECC 6.0.  I performed the migration with a homogeneous system copy, and everything has worked just fine.  I redefined the Linked Server on the new SQL 2005 installation, this time avoiding the alias and referencing the remote named instance directly, and it tests out just fine using queries from SQL Management Studio.  It also tests fine with OSQL called from the R/3 server console, both when logged on as SAPServiceSID with a trusted connection, and with a SQL login as the schema owner (i.e., 'sid' in lowercase).  From outside of R/3, I cannot make it fail.  It works perfectly.
That all changes when I try to use the Linked Server within an ABAP application, however.  The basic code in use is
EXEC SQL.
   SET XACT_ABORT ON
   DELETE FROM [SERVER\INSTANCE].DATABASE.dbo.TABLE
ENDEXEC.
The only thing different about this code from that before the upgrade/migration is the reference to [SERVER\INSTANCE] which previously used the alias of just SERVER.
The program short dumps with runtime error DBIF_DSQL2_SQL_ERROR, exception CX_SY_NATIVE_SQL_ERROR.  The database error code is 15274, and the error text is "Access to the remote server is denied because the current security context is not trusted."
I have set the "trustworthy" property on the R/3 database, I have ensured SAPServiceSID is a member of the sysadmin SQL role, I've even made it a member of the local Administrators group on both source and target servers, and I've done the same with the SQL Server service account (it uses a domain account).  I have configured the Distributed Transaction Coordinator on the source (Win2003) system per Microsoft KB 839279 (this fixed problems with remote queries coming the other way from the SQL2000 system), and I've upgraded the system stored procedures on the target (SQL2000) system according to MS KB 906954.  I also tried making the schema user a member of the sysadmin role, but naturally that was disastrous, resulting in an instant R/3 crash (don't try this in production!), so I set it back the way it was (default).
What's really strange is no matter how I try this from outside the R/3 system, it works perfectly, but from within R/3 it does not.  A search of SAP Notes, SDN forums, SAPFANS, Microsoft's KnowledgeBase, and MSDN Forums has not yielded quite the same problem (although that did lead me to learning about the "trustworthy" database property).
Any insight someone could offer on this thorny problem would be most appreciated.
Best regards,
Matt

Answer 1

Good news! We have got it to work. However, we did it in something of
a backwards way, and I'm sure you'll laugh when you see how it was done. Also, the solution depends upon the fact that the remote server is still using SQL Server 2000, and so doesn't have quite so many restrictions placed upon it for distributed transactions and Linked Servers as SQL Server 2005 now does.
At the heart of the solution is the fact that the Linked Server coming FROM the remote server TO our SAP system works fine. Finally, coupled with the knowledge that using DBCON on the SAP side to the remote server also does actually provide a connection (see Notes 323151 and 738371), we set up a roundabout way of achieving our goal. In essence, from ABAP, we set up the DBCON connection to the remote server, at which point all the Native SQL commands execute in the context of the remote server. From within that connection, we
reference the tables in SAP via the Linked Server defined on the remote
server, as if SAP were the remote server, selecting data from SAP and inserting it into the remote (but apparently local to this connection) tables.
So, to spell it out, we define a Linked Server on the remote server pointing back to the SAP server as SAPSERV, with a SQL login mapping defined on the remote system pointing back to a SQL login in the SAP database. We also define a connection to the remote server from SAP using DBCON, using that remote SQL login for authentication.
Then, in our ABAP code, we simply do something along the lines of
exec sql.
   set connection 'REMOTE'
endexec.
exec sql.
   connect to 'REMOTE'
endexec.
exec sql.
   insert into REMOTE_TABLE
      select * from SAPSERV.SID.sid.SAP_TABLE
endexec.
exec sql.
   commit
endexec.
exec sql.
   disconnect 'REMOTE'
endexec.
This is, of course, a test program, but it demonstrated that it worked,
and we were able to see that entries were appropriately deleted and inserted in the remote server's table. The actual program for use is a little more complex, in that there are about four different operations at different times, and we had to resolve the fact that the temp table SAP_TABLE was being held in a lock by our program, resulting in a deadly embrace, but our developer was able to work that out, and all is now well.
I don't know if this solution will have applicability to any other customers, but it works for us, for now.
SAPSERV, REMOTE, REMOTE_TABLE, and SAP_TABLE are, of course, placeholder names, not the actual server or table names, so as not to confuse anyone.
Best regards,
Matt