oracle10gsqlplus

SQL Plus- no rows selected error;though the data has been inserted without any error


I am a very newbie with this SQL Plus and Oracle 10g thing.So,please don't mind the stupid questions.

See, what problem I am facing is that whenever i fire a query over a table;

SELECT * FROM emp;

The output comes out to be "no rows selected".

I am in utter dilemma as the table and its schema is clearly preserved but the data which I entered is not getting displayed. The same is happening for all the user generated tables. The tuples are not getting displayed. Is this the problem related to SQL Plus??? Kindly help and give me a proper guide.


Solution

  • In Oracle, every statement that you issue is part of a transaction. Those transactions need to either be committed (in which case the changes are made permanent) or rolled back (in which case the changes are reverted) before another session can see the data. Some databases either do not support transactions (i.e. MyISAM tables in MySQL) or do not implicitly start transactions (i.e. SQL Server). The Oracle approach is generally far superior-- when you inadvertently run a delete statement that is missing an important predicate, the ability to rollback the operation when it deletes many more rows that you are expecting can be a real career saver.

    In Oracle, when you've run whatever statements comprise your transaction and you are confident that your changes are correct, you need to explicitly issue a commit to make those changes visible to other sessions, i.e.

    SQL> insert into some_table( <<columns>> ) values( <<values>> );
    SQL> insert into some_other_table( <<columns>> ) values ( <<more values>> );
    SQL> commit;
    

    If you are really, really, really sure that you prefer the behavior you might be accustomed to in other tools, you can tell SQL*Plus to autocommit your changes

    SQL> set autocommit on;
    SQL> <<do whatever>>
    

    That is generally a really bad idea. The tiny benefit you get from not having to explicitly issue a commit is far outweighed by the ability to ensure that other sessions don't see data in an inconsistent state (i.e. if your transferring money from account A to account B by issuing two update statements, you don't want someone seeing an intermediate result where either both accounts have the money or neither account does) and the ability to rollback a change if it turns out to do something other than what you expected.