Get column creation date? - database

i am using oracle 11. I need to find when specific column was created. I know we can find out last DDL change date but first i created the column
and after some days created index on one of the column of same table . So now, I need to find when that specific column was created .
Is there a way ?

This depends on your audit settings if the object was being audited you may find it in audit trail. I'd suggest reading
http://docs.oracle.com/cd/B28359_01/server.111/b28337/tdpsg_auditing.htm
Or you can use LogMiner to check redo logs if you DB was running in ARCHIVELOG mode. But I have never used this so I'm not sure about all the requirements there.

Related

Retrieve Overwritten View SnowFlake

Problem: I have accidentally overwrite a view in SnowFlake using CREATE OR REPLACE VIEW.
Question: Is there anyway to retrieve the old view i.e. the SQL code?
You can use QUERY_HISTORY to find the previous DDL used to create the query.
You can filter results using QUERY_TYPE which will help to you to find quickly the right query type.
If you can't find it in the query history tab using QUERY_TYPE > CREATE, you can search for it over the previous 365 days in the query history. This previous post has the SQL to run:
View DDL history of CREATE VIEW statement in Snowflake
Note that this is a big query if your account has run lots of queries over the last year. You can modify it to reduce the scan if necessary if you know more information, such as the month of creation.
If you want a totally informal and lightweight way to version your objects, I wrote one for my internal use that I decided to share. It's a table and stored procedure. Call the stored procedure with the object type and three-part name, and it adds a version row to the table. If it finds a pervious version, it marks the old one obsolete as of the current_timestamp and increments the number of the new version by 1.
https://github.com/GregPavlik/SimpleVersioning/blob/main/install.sql

Linked SQL Server's table shows all fields as #Deleted, but when converted to local, all information is there

My company has a really old Access 2003 .ADP front-end connected to an on-premise SQL Server. I was trying to update the front-end to MS Access 2016, which is what we're transitioning to, but when linking the tables I get all the fields in this specific table as #Deleted. I've looked around and tried to change some of the settings, but I'm really not that into SQL Server to know what I'm doing, hence asking for help.
When converting the table to local, all the info is correctly displayed, so it begs the question. Also, skipping to the last record will reveal the info on that record, or sorting/filtering reveals some of the records, but most of the table stays "#Deleted"...
Since I know you're going to ask: Yes, I need to edit the records.. Although the snapshot method would work for people trying to view the info, some of us need to edit it.
I'm hoping someone can shed some light on this,
Thanks in advance, Rafael.
There are 3 common reasons for this:
You have bit fields in SQL server, but they are null. They should be assigned a default of 0.
The table in question does NOT have a PK (primary key).
Last but not least you need (want) to add a timestamp column. Keep in mind that this is really what we call a “row version” column (so it not a date/time column, but a timestamp column). Adding this column will help access determine if a record been changed, and this is especially the case for any table/form in Access that allows editing of “real” number data types (single, double). If access does not find a timestamp column, then it reverts to a column by column comparison to determine table changes, and due to how computers handle “real” numbers (with rounding), then such comparisons often fail.
So, check for the above 3 issues. You likely should re-run the linked table manager have making any changes.

How to create a copy of a record that has a timestamp value

I am working in SQL Server 2008 R2 and have a production table that I need to replicate exactly in another location to work on. I will first run a job to move everything over (once off) and then run a daily job to update the updates/inserts daily.
The daily job will look at the production table and find any new values that need to be inserted (based on a created date) and also find any existing values that need to be updated (based on a modified date). Any new values are inserts and any modified values are updates.
The job pulls these rows from the production table and applies them to the copy table located elsewhere. I am running into trouble with timestamp columns. The production table has a timestamp column and I don't know how I should handle this when updating the copy table (also created as a timestamp column).
I get an error if I set the production.timestamp_col = copytable.timestamp_col (Cannot update a timestamp column).
Should I leave it out (in which case I don't have an exact copy of the table), convert the column in the copy table & the value in the select from the production table to something else (not sure what), put my own value in (again, won't have an exact copy of the table) or drop/truncate and recreate each time (inefficient due to data volumes)?
What would the best approach be in a situation like this?
Thanks
You can convert the destination timestamp column to varbinary(8) and then insert the values. This will help you create an exact copy but it will break the timestamp functionality. Do this if you need to have a copy only. The actual purpose of timestamp column is to track changes to a row through versioning.
In SQL a timestamp column is system generated, you cannot update it or set it on insert. SQL does this all for you.
https://technet.microsoft.com/en-us/library/ms182776(v=sql.110).aspx
You may be able to pull something off with replication/mirroring to get a 100% exact copy, but it may not be worth it depending on your needs.

Adding a column to a table in SQLite

I've got a table in SQLite, and it already has many rows stored in it. I know realise I need another column in the table. Up to now I've just deleted the database and started again because the data has just been test data. But now the data in the database can't be deleted.
I know the query to add a column to the table, my question is what is a good way to do this so that it works for both existing users and new users? (I have updated the CREATE query I have for when the table is not found (because it's a new user or an existing user has cleared the database). It seems wrong to have an ALTER query in software that ships, and check every time. Is there some way of telling SQLite to automatically add the column if it doesn't exist during the UPDATE query I now need?
If I discover I need more columns in the future, is having a bunch of ALTER statements on startup (or somewhere?) really the best way to do it?
(If relevant this is for a node js app)
I'd just throw a table somewhere that marks what version of your database it is, and check that to determine if an update is needed. Either that or if you have a table already where there's always going to be just one record in it add a new field 'DatabaseVersion' to it.
So for example if you check the version number, and find it's a version 1 database when the newest version should be version 3, you know which updates to perform on it.
You can use PRAGMA user_version to store the version number of the database and check if the database needs to be updated.

Query to identify the number of revisions made to a table

Is there any query which can return me the number of revisions made to the structure of a database table?
Secondly, how can I determine the number of pages (in terms of size) present in mdf or ldf files?
I think you need to create a trigger and store all changes to the table in a separate table. You can then use this table to get the revision history.
You can get last modify date or creation date of object in SQL Server.
For examle info on tables:
SELECT * FROM sys.objects WHERE type='U'
More info on msdn
Number of pages can be fetched from sys.database_files.
Check documentation
SQL Server doesn't keep track of changes so it can't tell you this.
The only way you may be able to do this is if you had a copy of all the scripts applied to the database.
In order to be able to capture this information in the future you should look at DDL triggers (v2005+) which will enable you to record changes.

Resources