your approach is correct, i run *.sql files in SQL Dev with F5 key and get output, used most recent version 3.2.2.
What version of SQL Dev are you running? Maybe it's a version related issue...
version is 3.2.20.09
A user had a similar problem yesterday, came down to their NLS parameters being incorrect in SQL Developer. What does el_ccn.sql do? Does it have queries that involve dates by chance?
It was a simple count of a table
select count(*) from ccn;
so no reason to involve dates.
I noticed your output from SQL Developer is null, it should show something, even if it's ZERO.
Can you restart SQL Developer and try again?
Also, if you execute the select count() command manually in your worksheet with ctrl-enter, does that return the same value as SQL*Plus?
I'll restart SQL developer later as I'm in the middle of something and have to leave soon - but I had already tried running the SQL in Developer before posting and it output the expected answer, as per SQL Plus. Hence my current perplexed state.
I just wondered if there was a setting somewhere I might be missing.
Thanks for your help, Elaine
sorry - got involved with something else...
I restarted Developer this morning after a PC reboot and still only get the heading and no count value when running @el_ccn script.
Can you create a new script called sqldev_test.sql and in it have something like
select * from scott.emp;
select count(*) from scott.dept;
And try running that? I'm wondering if there's a big problem in your setup with executing scripts, or if there's something in particular with your script we need to investigate.
If the above works, we might need to open up @el_ccn script and see what's what.
well - really not sure what's happening ....
I reset the test script, like you suggested, with a SELECT of columns from the table followed by the SELECT count(*). To add a bit of fairy-dust I added an alias to the COUNT(*) too.
Strangely only the COUNT(*) heading showed as before without any reference to the alias ...
Sounds as if it is something more fundamental is wrong. I think I'll defer this to our DBA to log a call with Oracle. unless anyone has any bright ideas.
Whenever some unexpected behavior occurs that is not a known bug, I always suspect corruption in the migrated settings / user preferences. The quickest way to test this is
1. Export any connection definitions you do not wish to lose.
2. Add the following line to your sqldeveloper.conf file ...
AddVMOption -Dide.user.dir=<path-to-user-preferences-folder>3. Restart the product without migrating any settings
The conf file is <sql developer home>\sqldeveloper\sqldeveloper\bin\sqldeveloper.conf. The ide.user.dir must be writable given whatever privileges your user has (and preferably on a non-network drive) and must differ from the default value SQL Developer uses (e.g., on Windows 7, C:\Users\<yourusername>\AppData\Roaming\SQL Developer).
If el_ccn.sql script works properly with the clean, default user preferences, then you can back out the change to the conf file, delete or rename the system3.2.20.09.87 folder in the default or original ide.user.dir folder, then restart the product, migrating or not migrating settings from a previous installation as desired.
Hope this helps,
thanks for the suggestion. Sorry for not getting back to this but priorites have pulled me away. I'll try to get time to look at this next week.
Thanks Gary - this fixed the problem.
After over an hour of constantly being logged out of the forum, I've managed to get to this forum to reply. Phew!