There is strange thing happened for one of my idm processes.

I have a target which inserts around 10,000 rows into a database table. Before inserting, the target deletes all rows in the table.

The strange thing is the deletion sometimes works and sometimes doesn't.

No errors on both data migrator and SQL server.


Anybody encountered the same issue before?

thanks,

Hi,

Before run the flow set the target properties - Set Prior to Load Option as Truncate Table and
Set Load Type as Insert record from memory.
While set the target properties like this Before inserting, it will truncate the data's in the target table then it will insert the data.

I agree, for a database that supports TRUNCATE it's a better choice than DELETE rows because there's no database logging. So there's no chance of the database log filling up and cuasing the delete rows to fail. It's also faster.

Thanks for your reply.

Actually there are several processes with the same issue. Since they were implemented by different developers, some of them use truncate and some of them use delete all rows. But they all have the same issue.

The weird thing is that on SQL server side there is no errors and looks like working properly. On the iway side, it's the same.

If we leave database alone assuming it works properly, do you think the SQL server adapter has a problem?

It seems the error handling of the data migrator process is so bad. I don't know underlying how it handles commit or rollbank in case there is an error on database side.

I think the error handling is quite good. You can see all kind off messages and you can even decide what kind of messages you want to see. All logging is turned off by default though, you just have to put it on.

If you choose truncate in the target options, and it doesn't work, then I would definitely open a case at IBI, this is a simple process and should work OK.

Meanwhile you can use this in a stored procedure to be sure the truncate is done before your process:

SQL SQLMSS
TRUNCATE TABLE [some target table]
END
SQL SQLMSS COMMIT WORK
-RUN

Hi Frans,

Is it the trace you are talking about?

I couldn't find anything related to the level of logging via Configuration.

thanks