If your source of truth is a SQL table and you don't get the info for insert, update and deletes already from source, then you need to work it out by comparing your newest data to what's already in SQL.  One way for full load could be:  In SAS create and populate a hash/digest value over all columns that need update if they change and add this new column to your SQL table.  On the next day download from the SQL table the primary key columns and the hash column to SAS and compare to your new data (where you also create this hash). Inserts: Primary key exists in the new SAS table but not in the SQL table Update: Primary key exists in both tables but  hash values differ Deletes: Primary key exists in the SQL table but not in the new SAS table   Given what you describe what I'd likely do next to keep coding simple: Add to the SAS table a column "action" with values I, U or D Upload (bulk or not) the data with an action into a SQL staging table Delete in your SQL table all rows from the staging table with a matching primary key and action D or U Insert into your SQL table all rows from the staging table with action U or I Deletes are slow but given your statement that Deletes and Updates are rather rare, keeping the code simple for the Updates is likely worth it.   The reason why I've asked for the size of the Primary key column(s) and the available memory: Given the size of your data you will want to avoid sorting. IF the Primary Key and the Digest value fit into memory then you could identify the delta (I, U, D) withing a single data step using a hash lookup table and without the need for the SAS table to be sorted. The hash lookup table would contain the Primary Key column(s) and the digest value loaded from SQL. ....and you could of course also create a hash value for the primary key columns should they be too wide. Having said that: With your volumes I would eventually not use md5 to hash the primary key but at least sha1. Collisions are rare but I've seen it once happen with md5 and with a lower data volume than what you've got.     ... View more

That looks useful but afaik there is nothing similar available in EG.  You could experiment if there is a VS code extension that gives you what you want for working with SAS code. ....that's of course only really worth it if your environment then also allows you to connect to a SAS Server via VS Code. ... View more

The 3rd party app with which SAS communicates doesn't "know" how SAS password encoding and decoding works. SAS must therefore send the password cleartext. This is also true for SAS Access where you're passing something like pw="{SAS005}6DDE667...." SAS will during runtime decode the password and send it cleartext to the database.   It appears such decoding is not implemented for proc http with oauth_bearer parameter and therefore you can't use a SAS encoded password but must send it cleartext.   Based on some Googling Databricks supports OAuth Token Federation - but SAS only fully supports it in the Viya version. ...and it would also require some setup.   For OAuth Bearer Token you could store your token in a secure location and access it during runtime (=not directly storing it in the script). Another option would be to wrap your code into a SAS macro that you compile secure into some permanent SAS catalogue - with the token provided as macro parameter when you compile the macro.   ... View more