On Oracle 11g XE I ran the following statement:
alter table le_customer drop column profile_id;
and then removed the equivalent column reference from a simple view on the table and recompiled the view successfully.
I then ran some PL/SQL that referenced the view and I started getting getting
ORA-00600: internal error code, arguments: [kkdcsaccc2], [], [], [], [], [], [], [], [], [], [], []
(however if I changed the PL/SQL to reference the table directly then the code worked)
I have dropped and recreated the view and also run "alter table le_customer move ..." successfully, however the error continues to occur with 100% consistency.
I have shut the database down and run dbv against the database .dbf files - no errors were reported.
I am running on a VM so I rolled the code back and removed the profile_id column reference from the view without physically removing the column from the le_customer table ...and everything then worked fine with my code. Then I ran alter table le_customer drop column profile_id; again and immediately the ORA-00600 re-occurred.
I rolled the VM back again then ran
alter table le_customer rename column profile_id to donald_duck;
.......then tested and everything worked fine.
I then ran
alter table le_customer drop column donald_duck;
...then tested again and got the ORA-00600 immediately.
So I am very sure that the problem is being caused by the "alter table le_customer drop column ;" statement and i am lost as to how to resolve it.
So, if anyone has seen this or has any ideas regarding a test / workaround I would greatly appreciate any info you are able to share - thanks!
My previous conclusion was incorrect ...as I have again seen the exact same problem, this time on 2 completely separate database builds. The problem table however remained the same one as before (ie. le_customer) and:
the schemas were identical on both databases
the identical query behaviour was consistent on both database
the query behaviour was consistent regardless of whether the simple
view or base table was queried
The query consistently succeeded when no where clause was present
the query consistently failed as soon as as a simple where clause
was added ie. "where id = 123"
failure occurred regardless of the where clause content ie. "where
code = 'ABC'" also failed
the "where clause" continued to cause query failure even after all indexes were
dropped from the table
...I began dropping constraints one by one from the table, rerunning the query each time
And on removing the following constraint, the query started working!
constraint le_cus_bus_case_chk check(allow_case_boo = 'F'
or
case_master_template is not null
)
A fairly innocuous constraint on the following 2 columns, where noticeably case_master_template is an xmltype stored "out of row"
...
allow_case_boo varchar2(1)
case_master_template xmltype
...
)
xmltype column case_master_template store as clob (disable storage in row)
To confirm this constraint to be the problem, on the other database deployment where the same behaviour was manifesting - and all indexes and constraints still existed on the table - , I dropped the above constraint only. Immediately the problem disappeared and the query started working reliably.
I then removed all constraints, indexes, foreign keys from the table other than this one, and the query continued to manifest the ORA-00600 reliably. On removing this constraint last, the ORA-00600 disappeared from both view and table query (regardless of where clause existence).
So while i have no visibility of the internal workings, I do believe that I have identified the culprit, and can fairly confidently provide the recommendation to others to first check constraints on xmltype type columns that may exist should ORA-00600 "kkdcsaccc2" appear. And I will be removing the constraint from the table.
I hope this proves useful to someone.
Related
I'm trying to make a foreign key. When I execute the query below, it returns blank with neither an explanation nor an error.
alter table MySQL."GrossHomeSales"
add constraint fk_zip_code
foreign key (nhs_prev_zip) references MySQL."Location" (zip_code);
You have not mentioned what your sql client is. If you are using psql, it does say ALTER TABLE when you make an alteration to a table. If instead you were using pgadmin 3, it would say something like
Query returned successfully with no result in 345 msec.
The reason that you are not seeing any output could be because this is really large table with several million rows, Then it could take a few minutes to create the index so don't expect instant output.
The other likely reason for not receiving any immediate response is because the table has been locked by another long running query.
Finally your question title says postgresql but your table has mysql in it's name?? (this is not related, just curious)
I saved a SQL table before deleting some information from it with the sql statment:
select * into x_table from y_table
After doing some operations, I want to get back some information from the table I saved with the query above. Unfortunately, MS SQL Server MGMTS shows an error saying that the table does not exist.
However, when I put the drop statement, the table is recognized - and the table is not underlined.
Any idea why this table is recognized by the drop table statement and not the select from statement. This seems strange for me.
EDIT:
Thank you
It may be that the table isn't underlined in your drop table command because its name is still in your IntelliSense cache. Select Edit -> IntelliSense -> Refresh Local Cache in SSMS (or just press Ctrl+Shift+R) and see if the table name is underlined then.
Edit:
Another possibility is that your drop table command might be in the same batch as another statement that creates the table, in which case SSMS won't underline it because it knows that even though the table doesn't exist now, it will exist by the time that command is executed. For instance:
None of the tables one, two, or three existed in my database when I took this screenshot. If I highlight line 6 and try to run it by itself, it will fail. Yet you can see that two is not underlined on line 6 because SSMS can see that if I run the whole script, the table will be created on line 5. On the other hand, three is underlined on line 9 because I commented out the code that would have created it on line 8.
All of that said, I think we might be making too much of this problem. If you try to select from a table and SQL Server tells you it doesn't exist, then it doesn't exist. You can't rely on IntelliSense to tell you that it does; the two examples above are probably not the only ways that IntelliSense might mislead you about the current status of a table.
If you want the simplest way to know whether an object with a given name (like x_table) exists, just use:
select object_id('x_table');
If this query returns null, x_table doesn't exist, regardless of what IntelliSense is telling you. If it returns non-null, then there is some object out there with that name, and then the real question is why your select statement is failing. And to answer that, I'd need to see the statement.
A lot of posts like this, you have to copy in 2 statements :
CREATE TABLE newtable LIKE oldtable;
INSERT newtable SELECT * FROM oldtable;
I've just had something very strange happen to me with a Firebird database.
I was trying to create a table, and the CREATE TABLE failed for some reason. But now it's stuck in a very strange state:
If I try to CREATE TABLE again with the same table name, it gives an error: the table already exists. But if I try to DROP TABLE that table, it gives an error: the table does not exist. Trying to SELECT * FROM that table gives the "table does not exist" error, and the name does not show up in the metadata query:
SELECT RDB$RELATION_NAME
FROM RDB$RELATIONS
WHERE RDB$SYSTEM_FLAG=0
So for some reason, the table really seems to not be there, but I can't create it because something somewhere indicates that it does exist.
Does anyone have any idea how to fix this? I've already tried closing all connections to that database, which has helped with inconsistency issues in the past, but this time it doesn't help.
You didn't give details about what was the error when you tried to create the table, so I cannot comment it. But RDB$RELATIONS is not the only system table affected when you create a table. Maybe you are now in an inconsistent situation where some information about that table exists in some system tables and doesn't exists in others.
Another option is corrupted indexes in the system tables, so the record is not there but the index think it still exists.
Try to do a backup/restore and see if it helps. It it doesnt work, try to search for records related to that "non created" table in the other system tables (RDB$RELATION_FIELDS, etc) and if you find any, try to delete them.
As a last option, you may create a new clean database with correct metadata and pump your data to it using IBDataPump.
I've written a SQL query for a report that creates a permanent table and then performs a bunch of inserts and updates to get all the data, according to company policy. It runs fine in SQL Server Management Studio and in Crystal Reports 2008 on my machine. However, when I schedule it to run on the server with SAP BusinessObjects Central Management Console, it fails with the error "Associated statement not prepared."
I have found that changing this permanent table to be a temp table makes the query work. Why would this be?
Some research shows that this error is sometimes sent instead of the true error. Other people reporting it talk of foreign key and (I would also assume) duplicate key errors.
Things I would check:
Does your permanent table have any unique constraints that might be violated? Or any foreign key constraints?
Are you creating indexes on the table after it has been created?
Are you creating any views over this permanent table?
What happens if the table already exists before the job is run?
What happens to the table if the job fails?
Are there any intermediate steps (such as within a stored procedure) that might involve additional temp or permanent tables?
ETA: Also check what schema the permanent table belongs to: is it usually created with "dbo"? Are you specifying that explicitly? Is there any chance that there might be a permissions problem?
That is often a generic error. Are you able to run it on the server as the account that it is scheduled to run as? It is most likely a permission error or constraint issue.
Assuming you really need a regular table, why it's not possible to create the permanent table once, vs creating it every time you run the query?
Recreating regular user table each time query runs does not seem right. But to make it work you may try to recreate the table in a separate batch or query (e.g. put GO in the script, that splits it into separate queries).
Regarding why it happens, I'm thinking about statement caching. Server compiles the query and stores the result for some time in case same query has to run again. So it's my speculation that it tries to run the compiled query which refers to the table you have already dropped and recreated under the same name. Name is the same, but physically it's a new table. You could hit some bug in the server this way. Just a speculation, it can be different kind of problem.
Without seeing code it's a guess, but being that you are creating a permanent table everytime you run the report, I assume you must be dropping the table at some point? (Or you'd have a LOT of tables building up over time.)
I suggest a couple angles to consider:
1) Make certain to prefix tables (perhaps by a session ID or soemthing) if you are concerned about concurrency/locking issues and the like so each report run has a table exclusive to itself.
2) If you are dropping the table at the end, instead adjust your logic to leave the table be. Write code that drops when you (re)start the operation. It's possible the report is clinging to the table and you are destroying it prematurely.
I have a staging table (stage_enrolments) and a production table (enrolments). The staging table isn't partitioned, the production table is. I'm trying to use the ALTER TABLE SWITCH statement to transfer the records in the staging table to production.
ALTER TABLE dbo.stage_enrolments
SWITCH TO dbo.enrolments PARTITION #partition_num;
However, when I execute this statement I get the following error:
ALTER TABLE SWITCH statement failed. Target table 'Academic.dbo.enrolments' is referenced by 1 indexed view(s), but source table 'Academic.dbo.stage_enrolments' is only referenced by 0 matching indexed view(s)
I have the same indexed view defined on dbo.stage_enrolments as I do on dbo.enrolments - although the view on enrolments is partitioned. I've tried recreating the views and their indexes checking that all options are the same but I get the same result. If I remove the index from the dbo.enrolments view then it works fine.
I have it working on another set of tables that have indexed views so I'm not sure why it isn't working for these. Does anyone have an idea as to why this may be occurring? What else should I check?
The problem has now been sorted. I've recreated the indexed view once again and it is now working. I haven't actually changed anything though other than the name of the index so I'm not sure what the problem was.