We have a table in our Oracle Database that was created from an actual script.
Ex:
Create Table AS (Select * from table).
I was hoping to recover the original script the table was created from as the data is quite old in the table, but needs this created table needs to be refreshed. This table is created with data from another live table in our database, so if there is a way to refresh this without the original query - I'm open ears. Any solutions are welcomed!
Thanks!
I suppose you could also do a column by column comparison of this table against all others to see which one (if any) matches it. Of course, this would only be a guess.
It would require that object to actually be a materialized view instead of a table. Otherwise you are probably left off with exploring logs. Beyond that I doubt there is any way to recover the original select statement used to create that table.
Related
I have two different databases. Let's say 'DbOne' and 'DbTwo'.
Is there any way to do the followings?
Create a view in DbOne
Transfer data in a particular table from DbTwo to the newly created view in DbOne.
I am using SSMS and still figuring out the appropriate query..
Please give me any advice.
You need INSERT / SELECT statement - eg.
INSERT INTO DbOne..NewView
SELECT * FROM DbTwo..SourceTable
However, depending on the structure of both tables, you may need to specify the particular columns in the SELECT statement, to match the structure of the target table. (By the way, note that data is always going into a TABLE - not a VIEW. You can do an INSERT into a VIEW, but only under certain conditions)
This is a really strange question. I have a dynamic SQL stored procedure that inserts data into a static table in the queried database. This table is referenced quite a lot in the query. So when I needed to change this table and add two new columns I deleted it and used the import wizard (Excel spread sheet) to create a new one and gave it that same name, so I didn't have to amend the SP. The SP works fine, however I also have this query outside of dynamic SQL and when I run it, it now fails.
At first I couldn't work out why but when I saw that it was failing on the INSERT INTO the newly created (but with the same name) table because there were too many columns to match the table. I ran a simple SELECT * FROM and it brought back the old table with the 3 columns it used to have and not the new table with 5 columns?
How can this table still exist if its been deleted? Its like a ghost table still remains?
Thanks
First check your temp table exists or not in your database.IF exists means drop your temp table and then create new one.
IF EXISTS(SELECT 1 FROM tempdb.dbo.sysobjects WHERE xtype in ('U') AND id =
object_id(N'tempdb..#your_tableName') )
DROP TABLE #your_tableName;
This is known behaviour with views and can be fixed by dropping and recreating the view. Not sure why it is acting the same way for a table. Possibilities I can think of -
It is a view
The new table was not created in the same database
Try dropping and recreating the sproc, for what it is worth
sometimes i face the following case in my database design,, i wanna to know what is the best practice to handle this case:::
for example i have a specific table and after a while ,, when the database in operation and some real data are already entered.. i need to add some required fields (that supposed not to accept null)..
what is the best practice in this situation..
make the field accept null as (some data already entered in the table ,, and scarify the important constraint )and try to force the user to enter this field through some validation in the code..
truncate all the entered data and reentered them again (tedious work)..
any other suggestions about this issue...
It depends on requirements. If the data to populate existing rows for the new column isn't available immediately then I would generally prefer to create a new table and just populate new rows when the data exists. If and when you have all the data for every row then put the new column into the original table.
If possible i would set a default value for the new column.
e.g. For Varchar
alter table table_name
add column_name varchar(10) not null
constraint column_name_default default ('Test')
After you have updated you could then drop the default
alter table table_name
drop constraint column_name_default
A lot will come down to your requirements.
It depends on your application, your database scheme, your entities.
The best way to go about it is to truncate the data and re - enter it again, but it need not be too tedious an item. Temporary tables and table variables could assist a great deal with this issue. A simple procedure comes to mind to go about it:
In SQL Server Management Studio, Right - click on the table you wish to modify and select Script Table As > CREATE To > New Query Editor Window.
Add a # in front of the table name in the CREATE statement.
Move all records into the temporary table, using something to the effect of:
INSERT INTO #temp SELECT * FROM original
Then run the script to keep all your records into the temporary table.
Truncate your original table, and make any changes necessary.
Right - click on the table and select Script Table As > INSERT To > Clipboard, paste it into your query editor window and modify it to read records from the temporary table, using INSERT .. SELECT.
That's it. Admittedly not quite straightforward, but a well - kept database is almost always worth a slight hassle.
I add a column of type tinyint and being set to not allow nulls in a table and generate the change scripts. The table has data in it at this time. The script has code that creates a temp table and inserts the data that is in the current table into. It then deletes the old table and renames this temp table to the same name as the original table. All fine and good. My question is, why if I do the same thing to another table (same field, but different table), the generate change script does not include this new table insertion code?
Any tips would be greatly appreciated!
If the table does not contain data, there is no need to rebuild the table. Essentially Management Studio "plays it safe" behind the scenes by generating the script this way if it thinks it can't do it simply by just modifying the table. In my experience, it often does this when it doesn't really need to, however there are exceptions ... for example if you add your column not at the "end" of the table. Rather than make changes in the UI and script them, I recommend becoming familiar with the ALTER TABLE command. Rebuilding the table in that manner can be catastrophic on a production system, and can usually be avoided.
I am trying to insert data from one table to another with same structure,
select * into tbltable1 from tbltable1_Link
I am getting the following error message:
There is already an object named 'tbltable1' in the database.
The SELECT INTO statement creates a new table of the name you provide and populates it with the results of the SELECT statement.
I think you should be using INSERT INTO since the table already exists. If your purpose is in fact to populate a temporary table, then you should provide a table name that does not already exist in the database.
See MSDN for more information on this.
If you are confident that tbltable1 is not required, you can drop the table first.
You may also want to consider using temporary tables...
Select * into ##MyTemporaryTable FROM tblTable1_Link
You can then use the temporary table in this session. (Ending the session should drop the temporary table automatically, if I remember correctly. It's been a while since I've worked with SQL Server).