There can be a deadlock only if two transactions use at least two resources(tables/rows) each. Is this the case in your transactions? Also deleting all rows from a table is inefficient. You may have to check if you can use TRUNCATE statement and its implications on transactions.
@IanWarburton, as @steve suggested you do not want to use TRUNCATE statement rather stick to DELETE statements! Here is a solution that might work for you. RDBMSs usually have some way of handling deadlocks. In SQL server, it is possible to set deadlock priority for a session. Idea is to set high priority for the session (main txn) which deletes existing rows and inserts new rows by reading the file you mentioned. For all other session transactions(other txns), set low priority so that these transactions will be made victim in case of deadlocks. This gives the main txn to execute to completion. You need to use SERIALIZABLE isolation level for the main txn. Other txns receive an error (1205) on deadlock, hence rollback their transaction and restart them.
You may refer to http://technet.microsoft.com/en-us/library/ms178104(v=sql.105).aspx for more information on deadlock detection and handling.