Was going to say that.

@OP:

One of the main skill a developer must have is being able to troubleshoot properly how their code behave.

Break your code in small pieces, check all of them with unitary test (formal or not) to validate their behavior then move to the next step. Never test everything in one shot or you will be overwhelmed by side effect bugs whom will distract you from the real root cause.

Being a programmer is not just coding but also testing and deploying (even locally).

That won’t avoid you being blocked by a silly mistake for hours, everybody did that at some point in their career, but that will reduce your frustration against yourself when you discover why the bug existed.

Do a pause, go walk, change the topic and the next time you look at your code, you will spot the obvious bug :-)

If you're not familiar with the table, use a select top 10 * from table if you're on sqlserver, postgresql uses limit and oracle has fetch.

Don't recommend select * without limits or conditions unless you absolutely know the table, you can very quickly make a DBA unhappy

In those kinds of situations you need to remember to try to break the problem down into simpler sections to identify where the problem lies.

Learned that the hard way.

One of the first steps would be to run SELECT * FROM mainWorkSpace WHERE user_id = @user_id and see if that returns anything.

It's one of those situations where if i write something, i forget it because it is doing its thing and about selecting everything, i should've done that and it's my mistake.