I hope this answers your question.
If not, post a little sample data (CREATE TABLE and INSERT statements, relevant columns only) for all tables involved, and also post the results you want from that data.
If you're asking about a DML statement, such as UPDATE, the sample data will be the contents of the table(s) before the DML, and the results will be state of the changed table(s) when everything is finished.
Explain, using specific examples, how you get those results from that data.
See the forum FAQ {message:id=9360002}

977424 wrote:
This statement works, thank you. The only thing I did was add a distinct in order to get rid of the "single-row sub query..." error

DISTINCT isn't necessary; EXISTS sub-queries never raise the "... returns too many rows" error. In fact, EXISTS sub-queries stop as soon as they find a row. However, DISTINCT isn't doing any harm in this case.

In what case would I use the MERGE statement? Do you know which is faster (MERGE vs UPDATE)?

MERGE is a big improvement over UPDATE when the UPDATE statement has a sub-query in the SET clause, and then has a similar sub-query in the WHERE clause. Also, use MERGE instead of UPDATE when you need analytic functions.

I don't know of any good rules for guessing which is faster. In cases where I've seen a big difference, it was because UPDATE required redundant or complicated code, so I'd suggest that if MERGE looks tidier, then it's probably more efficient, too. Of course, in cases where efficiency is important, there's no substitute for actually testing both ways.
If there's an obvious, straightforward way to use UPDATE, I usually just do UPDATE. If performance is poor, then I'll look at MERGE as well.