ORA-14450: attempt to access the transactional temp table already in use - sql

Folks, I'm with this error:
ORA-14450: attempt to access the transactional temp table already in
use.
Can someone help me?

The session which locks the table is not committed/roll backed the changes.
Find out which session blocks that table and kill that session. or wait till that session commit/rollback the changes.

Related

MS ACCESS Lock a table during update, blocking

How can I lock a table preventing other users querying it while I update its contents?
Currently my data is updated by wiping the table and re-populating it (i know, its not the best way to update data, but the source data has no unique key to do a record by record update and this is the only way). There exists the unlikely, but possible scenario where a user my access the table in the middle of the update and catch it while it is empty thus returning bad info.
Is there at the SQL (or code) level a way to create a blocking statement that will wait for a DB update to complete prior to querying?
Access has very little locking capabilities. Unless you're storing your data in a different backend, you only can set a database-wide lock or no lock at all.
There is some locking capability setting table locks when the table structure of a table is being changed, but as far as I can find, that's not available to the user (neither through the GUI nor through VBA)
Note that both ADO and DAO support locking (in ADO by setting the IsolationLevel, in DAO by setting dbDenyRead + dbDenyWrite when executing the query), but in my short testing, these options do absolutely nothing in Access.

ORA-00054 error when trying to delete table

When I try this command on oracle sql-developer :
delete from my_table;
I get the following error :
ORA-00054: resource busy and acquire with NOWAIT specified
I haven't figured out how to solve this problem.
Someone or yourself(unintentionally) has a lock on the table.
Query the table V$LOCKED_OBJECTS to find the name of the user (you would want OS_USER_NAME) locking it.
You can ask the user to unlock the table. They will have to either commit/rollback their transaction. If they are unable to do so and permit you to kill their session, you can use the below:
alter system kill session 'sid, serial#'
to kill their session which has a lock on your table where 'sid' & 'serial#' is something you have to find by querying v$session,v$sqlarea tables.
This can also be done in SQL developer, you can find out the session (if your user has access to meta tables) from the menu Tools --> Monitor Sessions
Right click on the correct session record (very important) and select mark for kill. You should be able to delete the records once the session is killed.
Check with database admin. They can check if anything is going on with the table. May be someone is performing something on the table in different session. Admin can kill the session. Then, you will be able to delete/truncate the table.

SQLite Temp view/table in background thread

I am creating a temp view/table on the database from one thread, I then try to access that temp table in a background thread and I can't access the temp tables. I understood that the same process could see the temp tables, but I can't, I get a no such table... in ...
How can I access temp views/tables from other threads, within the same process?
I am using blocks, and opening a new connection when the block executes, running the query/statements then closing the connection.
Temporary tables/views are local to the database connection.
You have to share a database connection (which would require additional synchronization), or attach another database file with a known name in each connection.

In Oracle can you create a table that only exists while the database is running?

Is there a way in Oracle to create a table that only exists while the database is running and is only stored in memory? So if the database is restarted I will have to recreate the table?
Edit:
I want the data to persist across sessions. The reason being that the data is expensive to recreate but is also highly sensitive.
Using a temporary table would probably help performance compared to what happens today, but its still not a great solution.
You can create a 100% ephemeral table that is usable for the duration of a session (typically shorter than the duration than the database run time) called a TEMPORARY table. The entire purpose of a table in memory is to make it faster for reading from. You will have to re-populate the table for each session as the table will be forgotten (both structure and data) once the session completes.
No exactly, no.
Oracle has the concept of a "global temporary table". With a global temporary table, you create the table once, as with any other table. The table definition will persist permanently, as with any other table.
The contents of the table, however, will will not be permanent. Depending on how you define it, the contents will persist for either the life of the session (on commit perserve rows) or the life of the transaction (on commit delete rows).
See the documentation for all the details:
http://docs.oracle.com/cd/E11882_01/server.112/e25494/tables003.htm#ADMIN11633
Hope that helps.
You can use Oracle's trigger mechanism to invoke a stored procedure when the database starts up or shuts down.
That way you could have the startup trigger create the table, and the shutdown trigger drop it.
You'd probably also want the startup trigger to handle cases where the table exists and truncate it just in case the server stopped suddenly and the shutdown trigger wasn't called.
Oracle trigger documentation
Using Oracle's Global Temporary Tables, you can create a table in memory and have it delete the data at the end of the transaction, or the end of the session.
If I understand correctly, you have some data that needs to be processed when the database is brought online and left available only as long as the database is online. The only use-case I can think of that would require this is if you're encrypting some data and you want to ensure that the unencrypted data is never written to disk.
If this is actually your use-case, I would recommend forgetting about trying to create your own solution for this and, instead, make use of Oracle's encrypted tablespaces or Transparent Data Encryption.

Teradata locks - How to know if a table is locked?

Is there a way to know if a table is locked and what kind of lock is currently on a table? I was hoping for something through the DBC tables in teradata, but I can't find any reference to anything like this. I have normal user access and the DBA is no help. Thanks.
AFAIK only DBA utilities are available to determine the type of lock on a table.
With only user-level rights you can do something like the following (from here):
Lock Table dbName.myTable for Access nowait
Select * from dbName.myTable;
And according to the master himself (Geoffrey Rommel):
If the table is locked, you will get
error 7423, "Object already locked and
NOWAIT. Transaction Aborted."