How to fix Error 5035 on Windows Server 2025 / Windows 11

by

Troubleshooting Guide: Error 5035 – Filegroup Already Exists in Database

Why This Error Happens

This error occurs when a Transact-SQL statement attempts to create a filegroup using a name that is already registered in the sys.filegroups system catalog view for that database. SQL Server enforces unique filegroup names per database, so this typically results from a duplicate entry in a deployment script, a naming collision during a database restore/migration, or a developer re-running a schema creation script without first checking for existing objects. It can also surface during automated CI/CD pipeline deployments where idempotency checks are missing.

Step-by-Step Resolution Guide

Step 1: Verify the Existing Filegroup Name

  • Open SQL Server Management Studio (SSMS) 21 or Azure Data Studio and connect to the target instance.
  • Run the following query to list all current filegroups in the database:
  SELECT name, data_space_id, type_desc, is_default 
  FROM sys.filegroups;
  • Confirm whether the filegroup name in your error message (e.g., FG_SalesData) already exists in the result set.

Step 2: Decide Whether to Reuse, Rename, or Remove

  • If the existing filegroup is empty and not needed, remove it using:
  ALTER DATABASE [YourDatabaseName] REMOVE FILEGROUP [FG_SalesData];
  • If the filegroup contains data files and is still required, rename your new filegroup in the script instead (e.g., change FG_SalesData to FG_SalesData_v2).
  • If you intended to use the existing filegroup rather than create a new one, simply remove the CREATE FILEGROUP statement from your script.

Step 3: Modify and Re-Run the Deployment Script

  • Open the .sql deployment file (commonly located in C:\DeploymentScripts\ or your DACPAC/SSDT project folder).
  • Add a conditional existence check before the CREATE FILEGROUP statement:
  IF NOT EXISTS (SELECT 1 FROM sys.filegroups WHERE name = N'FG_SalesData')
  BEGIN
      ALTER DATABASE [YourDatabaseName] ADD FILEGROUP [FG_SalesData];
  END
  • Save the script and re-execute it against the target instance.

Step 4: Check for Duplicate Entries in Deployment/Migration Tools

  • If using SSDT, EF Core Migrations, or Flyway, inspect the migration history table (e.g., __EFMigrationsHistory or schema_version) for duplicate or out-of-order migration entries.
  • Clear any stale cached build artifacts in bin\ or obj\ folders if using Visual Studio 2022/2025 SSDT projects, then rebuild the project.

Alternative or Verification Steps

  • Re-run the original failing script or deployment pipeline and confirm it completes without throwing Error 5035.
  • As an alternative, use sp_helpfile or query sys.database_files joined with sys.filegroups to cross-verify that the filegroup-to-file mapping is correct and no orphaned references remain before retrying the operation.