In my Application, I need to create few temporary tables. Do I need to execute the SQL in each session to create temp tables else can I run the SQL manually once, and can use those temporary tables in each session?
From the fine manual:
Temporary Tables
Although the syntax of CREATE TEMPORARY TABLE resembles that of the SQL standard, the effect is not the same. In the standard, temporary tables are defined just once and automatically exist (starting with empty contents) in every session that needs them. PostgreSQL instead requires each session to issue its own CREATE TEMPORARY TABLE command for each temporary table to be used. This allows different sessions to use the same temporary table name for different purposes, whereas the standard's approach constrains all instances of a given temporary table name to have the same table structure.
So temporary tables are local to each session and each session will need its own CREATE TEMPORARY TABLE and the temporary tables will be different in each session even if they have the same name.
Related
I have some local temporary tables that I can't drop them, would you know if there is any way to drop them?
Example:
It's like they don't exist for me
Those are the internal names given to table variables or currently idle cached temporary tables for stored procedures.
You can't drop them with DROP TABLE.
For table variables/temp tables that are cached as part of an execution plan context then evicting the plan from the cache will also drop the table but you shouldn't do this.
Suppose a temp table would be created and dropped during a stored procedure. What if multiple users run the stored procedure at the same time, does it cause any problem like unable to create that temp table because it's been already created by another user and hasn't been dropped yet in time before someone tries to create that temp table?
As long as you're talking about an actual #temp table (with a single #) there are no problems. A #temp table is scoped to the session. So you can have dozens of people on the same instance, all creating temp tables with the exact same name, at the exact same time and you'll never have a collision. (It's a different story if you're talking about ##globaltemp tables (with 2 ##)... Global temps can and do collide with other sessions)
I want to rename a column in a table. I see two approaches
Use sp_rename() and modify stored procedures to refer to new name.
Create new column, copy data from old column to new column, modify stored procedure etc. to refer to new column, eventually drop old column.
We can't use #1 as renaming column might leave stored procedures broken and we cannot afford any downtime.
If we go with #2, there is possibility that both old and new columns would co-exist for sometime after the data is copied over from old to new column but before the stored procedures deployed to use the new column.
Is there any way to keep the new column in sync with any updates/insert/deletes done to old column?
Can the AFTER triggers help here? But triggers usually increase the transaction time, so may not be a favorable solution.
Can I replicate data between two columns of the same table?
Any other possible solutions?
Also does sp_rename() cleanly updates all the references to the column - like stored procedures, functions, indexes etc?
First confirm there are no references to the column from outside the database like application code directly querying the column without going through stored procedures.
Here is how I renamed the column without causing the downtime -
Add a new column besides the existing column. The new column has same data type as the old column but the new name.Also create indexes, modify replication etc. on the new column based on the use cases.
Modify all stored procedures writing (insert/update operations) to the old column to also insert/update in the new column.
Copy over the data from old column to the new column for the existing records. Step 2 and 3, together, now ensure that the new column will remain in sync with the old column.
Modify all stored procedures reading from the old column to now read from the new column.
Now that all code has transitioned to use new column, we need to clean up -
Modify stored procedures from earlier Step#2 to stop referring to old column.
Drop the old column.
You could rename your table and create a view using the old table name and have the view include an alias for your column.
SQLPrompt by redgate has a feature called Smart Rename which can rename a column and update all of the references to the new name.
From SQL Prompt 7 documentation:
SQL Prompt can create a script that allows you to rename objects in your database without breaking dependencies. You can rename the following:
Tables (including columns)
Views (including columns)
Stored procedures (including parameters)
Functions (including parameters)
When an object is renamed:
SQL Prompt also modifies any objects that reference, or are referenced by, the renamed object to ensure that dependency links are not broken.
If you have previously renamed an object using SQL Server Management Studio or Enterprise Manager Rename, or the T-SQL sp_rename command, the object definition will contain the original name.
Any objects that reference this original name are not updated.
To help you locate objects that reference objects that no longer exist, see Finding invalid objects.
The original permissions and extended properties of the object are preserved.
My company has an application with a bunch of database tables that used to use a sequence table to determine the next value to use. Recently, we switched this to using an identity property. The problem is that in order to upgrade a client to the latest version of the software, we have to change about 150 tables to identity. To do this manually, you can right click on a table, choose design, change (Is Identity) to "Yes" and then save the table. From what I understand, in the background, SQL Server exports this to a temporary table, drops the table and then copies everything back into the new table. Clients may have their own unique indexes and possibly other things specific to the client, so making a generic script isn't really an option.
It would be really awesome if there was a stored procedure for scripting this task rather than doing it in the GUI (which takes FOREVER). We made a macro that can go through and do this, but even then, it takes a long time to run and is error prone. Something like: exec sp_change_to_identity 'table_name', 'column name'
Does something like this exist? If not, how would you handle this situation?
Update: This is SQL Server 2008 R2.
This is what SSMS seems to do:
Obtain and Drop all the foreign keys pointing to the original table.
Obtain the Indexes, Triggers, Foreign Keys and Statistics of the original table.
Create a temp_table with the same schema as the original table, with the Identity field.
Insert into temp_table all the rows from the original table (Identity_Insert On).
Drop the original table (this will drop its indexes, triggers, foreign keys and statistics)
Rename temp_table to the original table name
Recreate the foreign keys obtained in (1)
Recreate the objects obtained in (2)
I am facing a problem regarding global temporary tables in Postgres Sql. If two procedures:
A() having a temporary table say temp(id, name)
B() having a temporary table say temp(id, name, address)
then if the procedure A is called first and after that procedure B is called then the temp table remains with the structure i.e. temp(id, name) defined in the procedure A and vice versa and the column "address" as defined in procedure B is not found.
Please help me to find a solution???
If you really need to have explicit temporary tables, just create these with a unique name.
Anyway, the common approaches would be to handle it in SQL selects without explicit temporary tables, possibly extended by using with queries (common table expressions).
Basically you have two options.
The first is to make your tables unique so that they don't hit the same ones. This would be preferred if you are using these to store longer-term session-specific data. These could be named uniquely.
A second is that you can create, use, and drop your tables inside the same stored procedure so that stored procedure A can be generally guaranteed that relation temp does not exist when starting and the same with stored procedure B.