I have a table in a production server which occasionally has mysterious data occur in it. Is it possible to track the history of adding data to the table to find out why/who/when...? I am reluctant to put a trigger on the table (and it would only help for future checking) because the data volume is usually huge and this might affect performance.
I only have db-owner privilege, not sa privilege.
You can use a default value in a new column and save there the user name with SUSER_SNAME().
Example
CREATE TABLE [dbo].[Table_1](
[id] [INT] NULL,
[name] [NCHAR](100) NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Table_1] ADD CONSTRAINT [DF_Table_1_name] DEFAULT (SUSER_SNAME()) FOR [name]
GO
Related
I am going through college and I'm doing an database class where we're introduced to the SQL Server Management Studio, so I'm very new to all of this. That being said, I've been following along and keeping up, making sure to note his queries... However, I noticed something. In the queries I've been making while keeping notes of my class, I have the error "cannot drop table because it does not exist or you don't have permissions".
Now this is odd to me, as I am the only user of this laptop, I am basically the administrator, I've created the database and tables as per instructions and yet, this issue is popping up and I'm unable to run my queries to see how they work.
Here's a snippet of my code, though I'm not sure how much it'd help...
-- Dropping tables in case they already exist
drop table Movie
drop table Genre
drop table Theater
drop table MovieTheater
-- Create table
create table Movie
(
MovieID int not null constraint PK_Movie primary key,
Title varchar(200) not null,
Budget money null,
ReleaseDate date null,
GenreCode char(1) not null constraint FK_MovieToGenre references Genre(GenreCode),
Released bit not null,
MovieLength decimal(5,2) null
)
create table Genre
(
GenreCode char(1) not null constraint PK_Genre primary key,
GenreDescription varchar(30) not null
)
create table Theater
(
TheaterID int not null constraint PK_Theater primary key,
TheaterName varchar(100) not null,
Address varchar(50) not null,
City varchar(50) not null,
Province char(2) not null,
PostalCode char(7) not null,
PhoneNumber char(13) not null
)
create table MovieTheater
(
MovieID int not null,
TheaterID int not null,
StartDate date not null,
EndDate date null,
constraint PK_MovieTheater primary key (MovieID, TheaterID)
)
I attempted changing the permissions of the database but it wouldn't allow me. Other solutions I've looked up all assume that it's connecting to a database for other purposes (likely work related)
The error is pretty clear. cannot drop table because it does not exist. You can't DROP a table that doesn't exist, just as you can't CREATE a table that already exists.
In SQL Server 2016 and later you can use DROP TABLE IF EXISTS to drop a table if it exists. Since the oldest version in mainstream support is SQL Server 2019, you can reasonably expect that IF EXISTS will work on any new database
DROP TABLE IF EXISTS [dbo].[MyTable0];
In older, now unsupported, versions you had to check explicitly in an IF :
IF OBJECT_ID(N'dbo.MyTable0', N'U') IS NOT NULL
DROP TABLE [dbo].[MyTable0];
The SQL Server DROP TABLE IF EXISTS Examples shows all these options. Use DROP TABLE IF EXISTS unless you really need to work with an unsupported database version.
From your code, I think the problem is you tried to drop the tables before you created them
-- Dropping tables in case they already exist
drop table Movie
drop table Genre
drop table Theater
drop table MovieTheater
To drop the table if only it has already exist, you could try:
IF OBJECT_ID('tableName', 'U') IS NOT NULL
DROP TABLE tableName;
Explain:
The OBJECT_ID function returns the object ID of the specified table. If the table does not exist, it returns NULL. The 'U' parameter indicates that we are looking for a user-defined table.
The IF statement checks whether the table exists by checking the result of the OBJECT_ID function. Simple as that!
After rebuilding all of the tables in one of my SQL SERVER databases, into a new database, I failed to set the 'ID' column to IDENTITY and PRIMARY KEY for many of the tables. Most of them have data.
I discovered this T-SQL, and have successfully implemented it for a couple of the tables already. The new/replaced ID column contains the same values from the previous column (simply because they were from an auto-incremented column in the table I imported from), and my existing stored procedures all still work.
Alter Table ExistingTable
Add NewID Int Identity(1, 1)
Go
Alter Table ExistingTable Drop Column ID
Go
Exec sp_rename 'ExistingTable.NewID', 'ID', 'Column'
--Then open the table in Design View, and set the new/replaced column as the PRIMARY KEY
--I understand that I could set the PK when I create the new IDENTITY column
The new/replaced ID column is now the last column in the table, and so far, I haven't ran into issues with the ASP.Net/C# data access objects that call the stored procedures.
As mentioned, each of these tables had no PRIMARY KEY (nor FOREIGN KEY) set. With that in mind, are there any additional steps I should take to ensure the integrity of the database?
I ran across this SO post, which suggests that I should run the 'ALTER TABLE REBUILD' statement, but since there was no PK already set, do I really need to do this?
Ultimately, I just want to be sure I'm not creating issues that won't appear until later in the game, and be sure the methods I'm implementing are sound, logical, and ensure data integrity.
I suppose it might be a better option to DROP/RECREATE the table with the proper PK/IDENTITY column, and I could write some T-SQL to dump the existing data into a TEMP table, then drop/recreate, and re-populate the new table with data from the TEMP table. I specifically avoided this option as it seems much more aggressive, and I don't fully understand what it means for the Stored Procedures/Functions, etc., that depend on these tables.
Here is an example of one of the tables I've performed this on. You can see the NewID values are identical to the original ID.enter image description here
Give this a go; it's rummaged up from a script we used a few years ago in a similar situation, can't remember what version of SQLS it was used against.. If it works out for your scenario you can adapt it to your tables..
SELECT MAX(Id)+1 FROM causeCodes -- run and use value below
CREATE TABLE [dbo].[CauseCodesW]( [ID] [int] NOT NULL IDENTITY(put_maxplusone_here,1), [Code] [varchar](50) NOT NULL, [Description] [varchar](500) NULL, [IsActive] [bit] NOT NULL )
ALTER TABLE CauseCodes SWITCH TO CauseCodesW;
DROP TABLE CauseCodes;
EXEC sp_rename 'CauseCodesW','CauseCodes';
ALTER TABLE CauseCodes ADD CONSTRAINT PK_CauseCodes_Id PRIMARY KEY CLUSTERED (Id);
SELECT * FROM CauseCodes;
You can now find any tables that have FKs to this table and recreate those relationships..
I'm looking for how to track changes from a view in MS Sql-Server 2012. And, the role of the log-in user is Public. So, it's hard to do it.
For example, Assuming that there is the schema.
CREATE TABLE [dbo].[USER_CREDENTIAL](
[USERID] [nvarchar](48) NOT NULL,
[VALID_FROM] DATETIME NULL,
[EXPIRED_AT] DATETIME NULL,
[CREDENTIAL_ID] int NOT NULL,
CONSTRAINT [UNIQUE_USERID] PRIMARY KEY CLUSTERED( [USERID] ASC)
) ;
CREATE VIEW [VIEW_OF_USER_CREDENTIAL] as
SELECT * FROM dbo.[USER_CREDENTIAL];
It can be only permitted to access the view. The view will be changed when some data is inserted/updated/deleted from the USER_CREDENTIAL table. I will do query to the view.
I saw the document. I tried that, but the target to track should be the data table and the login user is lack of the role. I got the error message.
Object 'foo' is of a data type that is not supported by the CHANGETABLE function. The object must be a user-defined table.
I tried the following. I added the temporary table and the trigger which make changed-data be inserted to the temporary table when the view is changed. But, it was also failed because it was permission denied.
CREATE TABLE dbo.[CHANGES_FROM_A_VIEW] (
[VERSION] [int] IDENTITY(1,1) NOT NULL,
[USERID] [nvarchar](48) NOT NULL,
CONSTRAINT [UNIQUE_VERSION] PRIMARY KEY CLUSTERED ( [VERSION] ASC)
)
CREATE TRIGGER [SOMETHING_CHANGED] ON dbo.[VIEW_OF_USER_CREDENTIAL] ...
ALTER DATABASE database_name
SET CHANGE_TRACKING = ON (CHANGE_RETENTION = 2 DAYS,AUTO_CLEANUP = ON)
ALTER TABLE [CHANGES_FROM_A_VIEW]
ENABLE CHANGE_TRACKING WITH (TRACK_COLUMNS_UPDATED = ON)
SELECT * FROM CHANGETABLE(CHANGES dbo.CHANGES_FROM_A_VIEW, 0) AS C
Anyone knows any way to solve this?
Is there any use in creating a table and giving it default values in 2 steps? First with CREATE TABLE, then with ALTER TABLE for each column.Is is just matter of formatting preference? Or is there some more technical reason for doing this?
We have some create table scripts at my place defined like so:
CREATE TABLE [dbo].[TABLE_EXISTING](
[SYS_ID] [varchar](17) NULL,
[TYPE] [varchar](35) NULL,
[CODE] [varchar](12) NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[TMG_ITS_PROF_INST_REC_T] ADD DEFAULT (space((17))) FOR [SYS_ID]
GO
ALTER TABLE [dbo].[TMG_ITS_PROF_INST_REC_T] ADD DEFAULT (space((35))) FOR [TYPE]
GO
ALTER TABLE [dbo].[TMG_ITS_PROF_INST_REC_T] ADD DEFAULT (space((12))) FOR [CODE]
GO
Why or why shouldn't I go ahead and create new tables like so:
CREATE TABLE [dbo].[TABLE_NEW](
[SYS_ID] [varchar](17) NULL DEFAULT space(17),
[TYPE] [varchar](35) NULL DEFAULT space(35),
[CODE] [varchar](12) NULL DEFAULT space(12)
) ON [PRIMARY]
You can definitely use the "inline" style of creating the default constraint right with the table. I actually prefer it that way, because in my opinion, it makes it clearer which bits belong together - but at the same time, the table definition becomes a bit more involved and more complex.
BUT I would always recommend to name your constraints!
CREATE TABLE [dbo].[TABLE_NEW]
(
[SYS_ID] [VARCHAR](17) NULL
CONSTRAINT DF_TableNew_SysId DEFAULT space(17),
[TYPE] [VARCHAR](35) NULL
CONSTRAINT DF_TableNew_Type DEFAULT space(35),
[CODE] [VARCHAR](12) NULL
CONSTRAINT DF_TableNew_Code DEFAULT space(12)
)
because if you ever need to deal with a constraint (to disable or drop it), unless you've named it explicitly, it will have a nice, quite counter-intuitive system-provided name and that typically causes headaches and troubles. Name your constraints!
I prefer it all being done at once, in the create script. I assume the alters were added after the table was initially created. The scripts were kept separate so all environments can be updated as they need to be.
SQL Server management studio seems to generate table creation change scripts this way, perhaps thats why they are in this format:
CREATE TABLE dbo.Table_1
(
Id int NOT NULL,
Name nvarchar(50) NOT NULL,
Surname nvarchar(50) NOT NULL
) ON [PRIMARY]
GO
ALTER TABLE dbo.Table_1 ADD CONSTRAINT
DF_Table_1_Name DEFAULT N'Foo' FOR Name
GO
ALTER TABLE dbo.Table_1 ADD CONSTRAINT
DF_Table_1_Surname DEFAULT N'bar' FOR Surname
GO
ALTER TABLE dbo.Table_1 SET (LOCK_ESCALATION = TABLE)
GO
COMMIT
When I try to script a table CREATE from a database, it doesn't always script all the columns inside a single CREATE TABLE. Some of the columns will be added via ALTER TABLEs. Why is this? Is SQL server capturing the history of the schema modifications, and any columns added after the initial creation are scripted with ALTERS? The reason this matters is because I'm scripting tables to be used within a VS Database project and it can't handle the ALTER statements.
CREATE TABLE [dbo].[tblPackageType]
(
[PackageTypeId] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL,
[PackageTypeDesc] [varchar](50) NOT NULL
) ON [PRIMARY]
ALTER TABLE [dbo].[tblPackageType] ADD [EDIcode] [varchar](10) NOT NULL
ALTER TABLE [dbo].[tblPackageType] ADD [EDI211] [varchar](10) NULL
Is SQL server capturing the history of the schema modifications, and any columns added after the initial creation are scripted with ALTERS?
Yes.
If you want to get around this, you can alter the script to be a create including all the needed columns, and after you run it the updated definition will be saved.