My job stops executing after just a few rows, but there are thousands
My job reads an Excel file and depending on various logic either updates or inserts records into several tables in a database.
After adding the middle stage (the one that outputs only to an Excel file for logging) to catch items with no "SOLid" but to try and match against names instead, the job just runs for a short amount of time and then stops running. I have never seen this before, what can the reason be? There is no error output either.
Thanks.
More of the same, I have added an inner join lookup on the email_addr_bean_rel table (marked with yellow in the picture) that seems to freeze the whole job. Any ideas why this would happen? There is a commit at the end of the flow (look to the left).
I would really like to understand what stops an execution like this, and how to avoid it. The only thing I can think of is that a Commit is necessary somewhere in the middle of the flow, but is that even possible?
Having read a bit more on this forum I found recommendations to set "Commit on every" to 1 instead of 10000 which I have done for all the tMysqlOutput components, but the job still freezes.
This is most likely database locking. I suspect the "email_addresses" table you've circled is using a different session than the "email_addresses" table near the bottom of the job.
go through all of your DB input/outputs and make sure they are using an existing connection-- your tMysqlConnection_1
This is most likely database locking. I suspect the "email_addresses" table you've circled is using a different session than the "email_addresses" table near the bottom of the job. go through all of your DB input/outputs and make sure they are using an existing connection-- your tMysqlConnection_1
Loks like you're trying to update a row that's already been updated in another component. Why not split your job into 3 processes.
When you say 3 processes, do you mean 3 separate jobs or 3 subjobs within the same job?
Also, only one of the rightmost update/insert options can occur for each record since it is the rejects that are being funneled "downstream" in the job.
