Assuming you have 5 tables all have the same table structure you could code a single SQL statement like this:
SELECT * FROM TABLE1 WHERE COL1 = 'Hong Kong'
UNION ALL
SELECT * FROM TABLE2 WHERE COL1 = 'Hong Kong'
UNION ALL
SELECT * FROM TABLE3 WHERE COL1 = 'Hong Kong'
UNION ALL
SELECT * FROM TABLE4 WHERE COL1 = 'Hong Kong'
UNION ALL
SELECT * FROM TABLE5 WHERE COL1 = 'Hong Kong'
If you are concerned about searching all 5 columns, you can code the SQL like this and stil use UNION ALL.
SELECT * FROM TABLE3 WHERE COL1 = 'Hong Kong'
OR COL2 = 'Hong Kong'
OR COL3 = 'Hong Kong'
OR COL4 = 'Hong Kong'
OR COL5 = 'Hong Kong'
If you are REALLY talking about scanning every column in all tables in a database my first thought would be don't do it, find another way to answer your question or fix your problem.
I think if this is something that absolutely needs to be done, you might be better off using native database utilities to dump and search for the data. On a large database, native utilities are the only practical way of doing something like this.
If that isn't a good enough answer, then you could code something in Java that would get every text column of every table by using DatabaseMetaData and then looping through and creating one SQL for each table in the form I described in my earlier post. The SQL would be built programmatically in a tight loop so you are not hand coding any SQL and the Java coding to build the SQL is quite easy to do. Of course this same program might very well take years to run on some systems, but off hand, I cannot think of another way using JDBC.
Best of luck of to you!
> so what's the alternative?
Build a free-text index on the data as it goes in in the first place:
http://lucene.apache.org/java/docs/
If you've got a pre-existing database that you have to free-text index, then write a tool to build free-text indexes from it using Lucene, and run it as a batch job. That's very much *not* a preferable approach though.
> well you can select table_name from user_tables;
> and than iterate over the result
You are describing a DBMS specific solution which goes against most of the principles of using Java/JDBC. I described the correct way to do this, which is by using DatabaseMetaData which will work with most if not all vendors?databases. Your description is just an reiteration of what I stated except yours is specific to Oracle. There isn't anything in the OP's post that makes me think this is Oracle, but even if this were Oracle I would recommend the OP NOT implement the DBMS specific solution you are describing when the Java/JDBC API provides a strong vendor neutral solution using DatabaseMetaData.