On this page
Why it happens
Error 262 is a permission failure at the statement level. You asked SQL Server to run a data definition command (a DDL statement like CREATE TABLE, CREATE VIEW, CREATE PROCEDURE, or ALTER), and your login simply does not have the right to run that command in this database. The message names the exact permission and database: CREATE TABLE permission denied in database 'HR'.
This is different from error 229, which fires when you lack a permission (SELECT, EXECUTE, and so on) on an object that already exists. Error 262 is about the permission to run the command at all, before any object exists. In other words, 229 is "you may not touch that table", while 262 is "you may not create a table here".
It is severity 14, a normal permission check, not a server fault. It usually means an application or deployment login was set up with read and write data rights only, and is now being asked to change the schema. Statement permissions like CREATE TABLE are granted separately from data access.
Examples
CREATE TABLE permission denied
-- Connected as AppUser, who has data access but no DDL rights
CREATE TABLE dbo.AuditLog (
id INT IDENTITY(1,1) PRIMARY KEY,
action NVARCHAR(100),
logged DATETIME2 DEFAULT SYSUTCDATETIME()
);Msg 262, Level 14, State 1, Line 1 CREATE TABLE permission denied in database 'HR'.
CREATE PROCEDURE permission denied
-- Same login trying to add a stored procedure
CREATE PROCEDURE dbo.GetEmployees
AS
BEGIN
SELECT id, name FROM dbo.Employees;
END;Msg 262, Level 14, State 1, Line 1 CREATE PROCEDURE permission denied in database 'HR'.
How to fix it
Grant the specific statement permission
If the login should be allowed to create exactly this kind of object, grant just that statement permission. This is the least-privilege option: it hands over CREATE TABLE and nothing else.
USE HR;
GO
GRANT CREATE TABLE TO [AppUser];
-- Grant only what is needed, one statement permission at a time
GRANT CREATE PROCEDURE TO [AppUser];
GRANT CREATE VIEW TO [AppUser];Add the user to a database role that includes the right
For a login that needs to create, alter and drop objects during deployments, add it to the built-in db_ddladmin role, which grants the full set of DDL statement permissions. Use db_owner only when the account genuinely needs full control of the database.
USE HR;
GO
-- db_ddladmin can create, alter and drop objects
ALTER ROLE db_ddladmin ADD MEMBER [DeployUser];
-- db_owner grants everything; use sparingly
-- ALTER ROLE db_owner ADD MEMBER [DeployUser];Confirm which database and login you are actually using
The permission is per database, so a grant in one database does nothing in another. Check that you are connected to the database named in the message and running as the login you think you are before granting anything.
SELECT DB_NAME() AS current_database,
SUSER_SNAME() AS login_name,
USER_NAME() AS db_user_name;How to prevent it
Give DDL rights to deployment and migration accounts through roles such as db_ddladmin, and keep ordinary application logins limited to reading and writing data (db_datareader and db_datawriter). Schema changes should flow through the deploy account, not the runtime app login.
Grant statement permissions deliberately rather than reaching for db_owner. Document which login owns schema changes for each database, and review these grants as part of your security checks so no app login quietly accumulates DDL power it does not need.
Common questions
What is the difference between error 262 and error 229?
Error 262 is a statement permission failure: you lack the right to run a command such as CREATE TABLE or ALTER at all. Error 229 is an object permission failure: the command is allowed, but you lack SELECT, EXECUTE or a similar permission on a specific existing object. In short, 262 stops you before an object exists, and 229 stops you from acting on one that already does.
Which role grants CREATE TABLE permission?
The built-in db_ddladmin database role includes CREATE TABLE along with the other DDL statement permissions (create, alter and drop objects), so adding a user to it fixes the error. The db_owner role also includes it because it has full control of the database. If you only want CREATE TABLE and nothing more, grant it directly with GRANT CREATE TABLE TO [user] instead of adding a role.
Why does my app login get error 262 when it worked before?
The login almost certainly has data access but not DDL rights, and the code now runs a statement that creates or alters an object. Read and write permissions (db_datareader and db_datawriter) do not include CREATE or ALTER, so the first schema change trips error 262 even though queries ran fine.