Determine if JOIN resulted in any columns

I have a sql statement with multiple joins; sometimes there are records resulting from the joins and sometimes not. It is not an error when the joins are empty.

Is there a way to test whether a particular join is empty without having to trap the exception occurring when a resulting column is not found in the result set?

In other words, if, using JDBC, I execute the following sql statement:

select * from AA left outer join BB on AA.keyField = BB.keyField
  where keyField = "123"

I would like to know whether that join found any fields without having to trap an exception. If I then execute the java statement:

String valueString = rs.getString("BB.keyField");

I get an exception. I cannot compare rs.getString("BB.keyField") to null, because the getString throws an exception if it did not find any values in the join.

I hope this makes the question more clear, and I apologize for not having expanded on it more in the first place.


The query won't return columns with such names. It will just use the simple names of the columns (name, keyField, etc.). Execute the query inside your database query tool, and you'll see which names are assigned to the retrieved columns.

You should never do a select *, and always select specific columns. And you should assign aliases to columns if two columns have the same name:

select as aId, as aName, as bId, as bName from ...

And, then, you can safely use


Also, the exception thrown contains a message, which should help you identify the problem. Read it. And if you don't understand it, post it.

Need Your Help

Network Intrusion Detection System in Java..!

java security networking jpcap

I am planning on implementing a NIDS (Net Intrusion Detection System) in the Java programming language.

Sencha vs Wavemaker

javascript extjs vmware sencha-architect

I'm trying to decide between Sencha Architect 2 and Wavemaker. They both seem very similar. Of course Wavemaker is completely open source, and Sencha is only partially open source. For this reason ...