Executing a view severs connection to database

Question

I execute a SELECT statement on a query as follows:
SELECT * FROM LLU_V_MIN_AVG_MAX_BY_CLASS_04
It runs for about 10 seconds and I receive the following error message:
An error was encountered performing the requested operation:
No more data to read from socket
Vendor code 17410Error at line 1
Line 1 was the SELECT statement.
In addition, it broke the connection to the database in SQL Developer, and I have never had that happen before. At that point, I had to reconnect to the database on every window I had open in SQL Developer (to that database).
Here's the view:
CREATE OR REPLACE VIEW LLU_V_MIN_AVG_MAX_BY_CLASS_04 AS
SELECT P."TypeCode", P."Year", COUNT(P."Year") AS "HowMany",
MIN(V1."Done_in_QR" + V1."Done_in_axiUm") AS "MinPoints",
AVG(V1."Done_in_QR" + V1."Done_in_axiUm") AS "AvgPoints",
MAX(V1."Done_in_QR" + V1."Done_in_axiUm") AS "MaxPoints"
FROM PRODUCER P
INNER JOIN LLU_V_CLINIC_REQUIREMENTS_04 V1
ON P."Producer" = V1."ProviderID"
WHERE V1."CategoryID" = 62 -- TOTAL CLINIC POINTS
AND P."Year" BETWEEN 2 AND 4
AND P."TypeCode" IN ('D','I')
AND P."Inactive" = 0
GROUP BY P."TypeCode", P."Year"
Here's what I've tried so far:
1) drop and re-create the view LLU_V_MIN_AVG_MAX_BY_CLASS_04
2) drop and re-create the view LLU_V_CLINIC_REQUIREMENTS_04 (used by above view)
3) drop and re-create the view LLU_V_CLINIC_REQS_AXIUM_04 (used by above view)
4) drop and re-create the view LLU_V_PRODUCTION_DETAIL_04 (used by above view)
In all cases (except #1), issuing a SELECT * FROM <view> returned data, both before and after dropping and re-creating them. The only view on which I receive the above error message is LLU_V_MIN_AVG_MAX_BY_CLASS_04.
I am stumped - I have no clue what's going on.
Can a view become corrupt?
Any and all help will be gratefully received - any additional information you need in order to help, just let me know.
Thanks very much,
Carl

Answer 1

Thanks to both of you for your replies.
I am using SQL Developer to execute this statement - that's what was so puzzling to me - I had never seen an error message like that before. I tried this in versions 1.2.1 and 1.5.4 of SQL Developer and got the exact same results - the abovementioned statement ran for about 10 seconds and then my connection to the database was severed and I needed to re-connect to the database.
Version of Oracle is 10.2.0.1.0
Some background on the views with which I am working:
All of them are suffixed with _04. What I do - whether right, wrong or otherwise - is whenever I have to make significant changes to that particular set of views, I increment the 'version number' so that I have the old views to refer back to just in case. So, this set of views existed as view name _03 until I copied, modifed and saved them as view name _04. They were working perfectly as 'version' _03 - no weird error messages at all. I then copied them to 'version' _04 and proceeded to make my modifications. So far so good. There are two tables which also get 'incremented' like this. I issued the command ANALYZE TABLE table_name VALIDATE STRUCTURE CASCADE against both of them and it succeeded. Here are the four views I am working with, numbered for reference purposes:
1) LLU_V_MIN_AVG_MAX_BY_CLASS_04
2) LLU_V_CLINIC_REQUIREMENTS_04
3) LLU_V_CLINIC_REQS_AXIUM_04
4) LLU_V_PRODUCTION_DETAIL_04
1) is my problem child.
2) is used by (1)
3) is used by (2)
4) is used by (3)
2), 3) and 4) execute by themselves flawlessly. I issue the command SELECT * FROM +<any of those three views>+ and they return the correct dataset.
Also, 1) works flawlessly as LLU_V_MIN_AVG_MAX_BY_CLASS_03. All I did was copy it from _03 to _04, change the necessary view name within its code and save it and it's not working. The only view it (#1) references is LLU_V_CLINIC_REQUIREMENTS_04. I issue the command SELECT * FROM LLU_V_CLINIC_REQUIREMENTS_04 and it returns the correct dataset.
This is why I'm stumped and why I wondered whether a view can become corrupted.
I don't even know what to try at this point, but any and all advice will be gratefully accepted, as always.
Thanks,
Carl