How do I select stuff from table just created in PL/SQL script?

Question

When I execute a select statement, SQLplus complains about the table does not exist. But it has just been created? Dont know what is going wrong... thanks in advance...
Code is as follows:
DECLARE
column_table VARCHAR(50) := 'column_table';
r_count NUMBER(10) := 0;
BEGIN
column_table := UPPER(column_table);
-- I created the table here and commit
EXECUTE IMMEDIATE 'CREATE TABLE '|| column_table || ' (table_name varchar2(100), column_name varchar2(1000))';
commit;
IF someCondition THEN
blahblah
-- this is where SQLPLUS complains about the table or view does not exist
          select count(1) into r_count from column_table where table_name = someValue;
blahblah
END IF;
END;
/

Answer 1

Thanks for the additional detail
>
Better way of doing this?
>
I sure wouldn't do it that way.
My first approach would be to produce tables or views that show the differences. Then let the users examine the data or export the data to excel and send it to them.
This is what I have done in the past that has worked well. This assumes that Table1_pre and Table1_pos both have primary keys
There will be four result tables
1. Pre_but_not_Post - this table has records (primary keys) in the Pre table that are not in the Post table
2. Post_but_not_pre - opposite of #1 - records in Post table but not in Pre table
3. Pre_records_changed - this table has records in Pre that are also in Post table but at least one column value is different
4. Post_records_changed - this table has the Post table records that match #3
A. Create a view on Table1_pre that only includes the columns to be compared.
B. Execute four queries (not tested) to do the above data split - this lets Oracle compare the data in the two tables
1. Pre_but_not_Post - query the key values in the Pre table that are not in the Post table creating a new table to hold the result
CREATE TABLE PRE_BUT_NOT_POST AS
SELECT pre.key1 from Table1_pre pre
MINUS
SELECT post.key1 from Table1_post post
2. Post_but_not_Pre - query the key values in the Post table that are not in the Pre table creating a new table to hold the result
CREATE TABLE POST_BUT_NOT_PRE AS
SELECT post.key1 from Table1_post post
MINUS
SELECT pre.key1 from Table1_pre pre
3. Pre_records_changed - query the records from the pre table that are in the post table but are different - create a new table
CREATE TABLE PRE_RECORDS_CHANGED AS
SELECT PRE.* FROM Table1_pre pre, Table1_post post WHERE pre.key1 = post.key1
MINUS
SELECT POST.* FROM Table1_post post, Table1_pre pre WHERE pre.key1 = post.key1
4. Post_records_changed - query the records from the post table that are in the pre table but are different - create a new table
-- left as an excercise for you
The first two tables show you the records that aren't in one of the tables. The second two tables have the records that are different in some column.
In the past I have merged the second two tables into another table and added a flag (PRE or POST) to indicate which table the record came from.
Then I would export the new table in sorted order - ORDER BY KEY1, FLAG and export the file to delimited format. The file has every record that is different with the POST record immediately followed by the matching (on key) PRE record.
I created an Excel template with a formula in every cell of every even numbered row. The formula would compare the cell value in the row to the cell value in the row immediately above - this compares PRE to POST values for each column. If the value was different the formula would turn the cell RED.
Then I would open the delimited file in an Excel worksheet, copy the entire set of cells to the clipboard and then paste it into a copy of the Excel template.
Voila! - Every cell that was different was hightlighted in RED and easy to spot.
Users could examine the data at their leisure to determine what was wrong or needed to be fixed and the developer had the corresponding data in a table where it could be changed and then applied to the POST table as an update.
The above approach is very straightforward and easy to setup and implement. Even if you don't use it as your final solution it will make it easier to confirm that whatever solution you do adopt is correct.
I would recommend you try the above on a small number of records for one of your tables as a proof-of-concept. You should be able to easily adapt it for your particular requirements. For example, you may just need to write a report or custom query using the two tables from steps 3 and 4 above.