Which version of SQL server are you running?
Depending on the severity of the error, another nifty trick you could try to catch the errors would be to wrap everything that is suspect in TRY / CATCH blocks.
Firstly create a table like so...
CREATE TABLE [dbo].[ERROR_LOGGING](
[ErrorNumber] [int] NULL,
[ErrorSeverity] [int] NULL,
[ErrorState] [int] NULL,
[ErrorProcedure] [nvarchar](128) NULL,
[ErrorLine] [int] NULL,
[ErrorMessage] [nvarchar](4000) NULL,
[UpdateStamp] [datetime] NULL DEFAULT ( getdate() )
) ON [PRIMARY]
Then put your code in a try / catch block.
BEGIN TRY
--Code---
END TRY
BEGIN CATCH
INSERT INTO ERROR_LOGGING (
errornumber,
errorseverity,
errorstate,
errorprocedure,
errorline,
errormessage,
updatestamp)
VALUES (
ERROR_NUMBER(),
ERROR_SEVERITY(),
ERROR_STATE(),
ERROR_PROCEDURE(),
ERROR_LINE(),
ERROR_MESSAGE(),
getdate())
END CATCH;
This will catch any errors above a severity level of 16 and insert them into the table created in the first step.
Caveat of this is that try / catch blocks do not catch low level errors.
I've seen it a few times that data in a source or destination table is different to what is expected, i.e. strange characters, text instead of integers etc. If you still can't crack it run a sql server profiler trace against the databse while you run the procedure.
It shouldn't take long to find the problem. I won't go into how to use SQL server profiler as you only need to do a quick web search to find hundreds of detailed guides.