So, I got rid of wp_options db table by accident and I am trying to recreate or get the table back.
Is there a way of doing it without reset the whole wp db?
Thanks!
You can't restore it, unless you have a backup of it. Check with the service provider in case they have automated backup copy. Otherwise, Just try re-creating the table with the following queries. and activate the plugins again.
CREATE TABLE `wp_options` (
`option_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`option_name` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
`option_value` longtext COLLATE utf8mb4_unicode_ci NOT NULL,
`autoload` varchar(20) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT 'yes',
PRIMARY KEY (`option_id`),
UNIQUE KEY `option_name` (`option_name`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
Put your site url and run the following queries
INSERT INTO wp_options VALUES ('1', 'siteurl', 'YOUR_SITE_URL', 'yes');
INSERT INTO wp_options VALUES ('2', 'home', 'YOUR_SITE_URL', 'yes');
Then reactivate all the plugins. If any issues, revert back
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!
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
Goal
I aim to create SSIS (ETL) Template that enables audit functionality (Audit Dimension). I've discovered a few ways to implement audit dimension that are described below with some reference links below:
SEQUENCE
Primary Key
Best way to get identity of inserted row?
Environment:
There are millions of rows in a fact tables and packages run a few
times a day.
Incremental ETL gets thousands of rows.
SQL Server 2012 BI edition is used for the BI solution.
Simplified Schema of DimAudit table:
CREATE TABLE [dw].[DimAudit] (
[AuditKey] [int] IDENTITY(1 ,1) NOT NULL,
[ParentAuditKey] [int] NOT NULL,
[TableName] [varchar] (50) NOT NULL DEFAULT ('Unknown'),
[PackageName] [varchar] (50) NOT NULL DEFAULT ('Unknown'),
[ExecStartDate] [datetime] NOT NULL DEFAULT ( getdate()),
[ExecStopDate] [datetime] NULL,
[SuccessfulProcessingInd] [char] (1) NOT NULL DEFAULT ('N'),
CONSTRAINT [PK_dbo.DimAudit] PRIMARY KEY CLUSTERED
(
[AuditKey] ASC
)
) ON [PRIMARY]
ALTER TABLE [dw].[DimAudit] WITH CHECK ADD CONSTRAINT [FK_DimAudit_ParentAuditKey] FOREIGN KEY( [ParentAuditKey])
REFERENCES [dw]. [DimAudit] ( [AuditKey])
GO
ALTER TABLE [dw].[DimAudit] CHECK CONSTRAINT [FK_DimAudit_ParentAuditKey]
GO
Primary Key Option:
Primary key is generated in the audit table and then AuditKey is queried.
Task: Master SQL Audit Generates Key (SQL Task)
INSERT INTO [dw].[DimAudit]
(ParentAuditKey
,[TableName]
,[PackageName]
,[ExecStartDate]
,[ExecStopDate]
,[SuccessfulProcessingInd])
VALUES
(1
,'Master Extract Package'
,?
,?
,?
,'N')
SELECT AuditKey
FROM [dw].[DimAudit]
WHERE TableName = 'Master Extract Package' and ExecStartDT = ?
/*
Last Parameter: ParameterSystem::StartTime
Result Set populates User::ParentAuditKey
*/
Task: Master SQL Audit End (SQL Task)
UPDATE [dw]. [DimAudit]
SET ParentAuditKey = AuditKey
,ExecStopDT = SYSDATETIME()
,SuccessfulProcessingInd= 'Y'
WHERE AuditKey = ?
/*
Parameter: User::ParentAuditKey
*/
SEQUENCE Option:
The sequence option does not select primary key (AuditKey) but uses logic below to create next available AuditKey.
CREATE SEQUENCE dbo . AuditID as INT
START WITH 1
INCREMENT BY 1 ;
GO
DECLARE #AuditID INTEGER ;
SET #AuditID = NEXT VALUE FOR dbo. AuditID ;
Best way to get identity of inserted row?
It feels risky using identity options as ETL packages could be executed in parallel.
Question
What is the recommended practice for audit dimension table and managing keys?
Sequence & primary key options do the job; however, I have concerns about the selecting primary key option because package could be executed the same millisecond (in theory) and therefore, a few primary keys would exist. So, Sequence sounds like the best option.
Is anything better I could do to create Audit Dimension for a data mart?
You could use the OUTPUT syntax:
INSERT INTO [dw].[DimAudit]
(ParentAuditKey
,[TableName]
,[PackageName]
,[ExecStartDate]
,[ExecStopDate]
,[SuccessfulProcessingInd])
OUTPUT inserted.AuditKey
VALUES
(1
,'Master Extract Package'
,?
,?
,?
,'N')
or SCOPE_IDENTITY() which is what I'm personally using:
INSERT INTO Meta.AuditDim (
Date,
UserName,
Source,
SourceType,
AuditType,
ExecutionId,
ExecutionHost,
ParentAuditKey,
FileID
)
VALUES (
GETDATE(),
CURRENT_USER,
#Source,
#SourceType,
#AuditType,
#ExecutionId,
#ExecutionHost,
#ParentAuditKey,
#FileID
);
SELECT AuditKey FROM Meta.AuditDim WHERE AuditKey = SCOPE_IDENTITY();
I've setup a simple bootstrap page to insert rows in my db, but I can't get the db to save in the right format/charset.
I want it to support multiple languages since I'm saving beer names from different countries, but even when I set the collation to a specific language on the affected rows and only submit letters from that charset, it still doesn't save the letters right.
Here's a table I exported from the db:
CREATE TABLE IF NOT EXISTS `Favorites` (
`fav_id` int(11) NOT NULL AUTO_INCREMENT,
`user_id` varchar(55) CHARACTER SET utf8 COLLATE utf8_danish_ci NOT NULL,
`fk_beer_id` int(11) NOT NULL,
`fav_comment` varchar(255) CHARACTER SET utf8 COLLATE utf8_danish_ci DEFAULT NULL,
PRIMARY KEY (`fav_id`),
KEY `FK_FavBeer_Beer` (`fk_beer_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=7 ;
I get confused by the fact that (in PhpMyAdmin) I can set collations on both db, table and row.
Where and what collation is right for my db?
EDIT:
It may be because I'm using ajax to send the form:
I have the following settings:
contentType: "application/x-www-form-urlencoded; charset=UTF-8",
Solved it.
Used utf8_decode in the php file..
I have 2 tables called login and Roles.
In the login table, I have these fields:
CREATE TABLE [dbo].[login]
([Id] [int] IDENTITY(1,1) NOT NULL,
[Uname] [varchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
[Pwd] [varchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
CONSTRAINT [PK_login_1] PRIMARY KEY CLUSTERED([Uname] ASC)
In the roles table I have these fields:
CREATE TABLE [dbo].[Roles]
([Uname] [varchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
[Valid] [int] NOT NULL
)
Now what I need is if I fill the uname as some xyz I would like to fill the same uname in the role table automatically in the corresponding field that i makes as foreign key...
You could do this using a Trigger. You may or may not want to execute this code on an Insert and / or Update Further details on triggers can be found here
CREATE TRIGGER trgInsertUserIntoRoles ON Login
FOR Insert
AS
INSERT INTO Roles (UName, Valid)
SELECT Uname, 1
FROM Inserted
Although I think it would be better if you just added the code to insert the username into the Roles table within the Stored Procedure to create the user.
Also, you are aware that you are creating all this on the master database?
A solution is to put a trigger on inserts to the original table.
This microsoft article on triggers will tell you how they work.