Also there's no reason to do del connection because it's not like that object is taking up any memory.
And if you handle your commits/transactions in sql you don't need to worry about batching the executions in python. An Engine object does not actually establish a connection but doing something like engine.execute(sql) will open the connection and execute the statement and close the connection but leave your engine object available for more if you want. Also there's some unnecessary connection shit you're doing with sql alchemy. What seems to be happening is you aren't closing that connection properly and it's opening a new one causing SQL to lock sa for whatever reason. I would control your transaction blocks in SQL instead of in python. You don't want to be using the sa account from an external application, even if it's just a python script.
Create that login in sql and give it just the permissions it needs, not full blown sys admin - we do this through a dba role we created. If you are a windows org, have your sys admin create an AD group called something like domain\DBA and have them add yourself and whoever else to it. Whats that one look like You will always receive a. First paragraph is optional and unrelated to the actual issue There should be an error in the event log as well that looks like Error: 18456, Severity:, State. By default it will try to connect to master DB where this user may not exists there as AAD users are contained inside each user database. Net SqlClient Data Provider) If you are connecting from SSMS you may also need to change the default database option (Image below).
"because we've always done it" is my absolute least favorite thing to hear in the IT world. Login failed for user 'The reason i use sa is because people in my group all have have been using it for years and i rather keep things as is