Blocking and deadlocks are a part of life in the database world. Blocking to the point of timeout will have a serious impact to the concurrency of your application. Of course, I don't know of many applications that routinely delete 500K rows.

-Mike

>>If you're still getting an error, use the SQL Profiler to capture what's being sent to the server.
>>
>>-Mike
>
>Hi Mike,
>
>I'm certain that the issue isn't the contents of the file I'm using for the Bulk Insert (I've run it through about 50 times with out changing the format during testing today).
>
>On one occasion, from QA, I ran a script to delete all the records from the import table (approx. 500,000) and a few other tables.
>
>While QA was deleting the records (i.e. before it had finished) - I ran the VB program and tried to do the import again. I think that the server was 'busy' trying to delete the records and the Bulk Insert timed out. (Note: This was the only instance - out of 50 or so - where I received an error message indicating that I couldn't connect to the server to do the bulk insert.)
>
>Does this make sense? If so, I would like my VB app to trap for this error, advise the user, and do all that good and wonderful stuff that should be done when there are problems during a file import. (i.e. roll-back what has already been done)
>
>Al