Timeouts can happen for so many reasons, its just the nature of SQL database in production environment with many users doing all kinds of stuff.
If you have an import using eConnect, then it is up to you as the developer how to handle errors arising from eConnect requests.
Where I'm using eConnect, I code it to retry like 30secs/1min after a timeout, then have a time squared back off rule, where I try less and less often to get the transaction to submit, then raise error after a threshold number of re-tries or time trying. If the SQL server has locked up, you really don't want to be adding more stress with your transactions, hence the backing off.
If the order is locked because a user is in that record (concurrency issues), econnect will see the lock record in tempdb..DEX_LOCK and then raise an econnect error 2079 Document is currently being edited by another user. That is different to timeout.
Note that econnect will also lock the order using DYNAMICS.dbo.taDEXLOCKS procedure, so no one else can edit while eConnect is editing, its a good responsible database citizen.
If you are seeing a lot of time outs it might be worth getting into a SQL server health check project. Set some extended event session in SQL to monitor for session time outs and another for deadlocks. Do the normal checking indexes are healthy and SQL stats up to date etc etc.
Tim
