Make sure you have truly shrink the files with DBCC SHRINKFILE (gm_data, 25600) When you recover a SQL database you'll find it will always create the same files, that's not to say you can't change the file paths. The best way to eliminate unwanted files and filegroups, is to: - create a new database with the desired files and filegroups. - create the tables without any Primary Keys, indexs, or other constraints. - Then insert the data in each table by writting a select statements. - then add back the remaining database objects. You can use SQL's scripting ability to generate scripts, but this will require some editing on your part. I've frequently edited scripts to control where tables and indexes will be creates. Note all stored procedures, triggers, and functions will be stored on the default filegroup. I will typically edit scripts to seperate them by database object, i.e. tables only, then primary keys, indexes, other constraints like foreign keys and check constraints, stored procedures, triggers, functions, database roles, grants, etc. I know this is a lot of work, but the final result will be you know where every object is stored in your database and you won't run into a table being stored across three different files on one or more logical drives.

Make sure you have truly shrink the files with DBCC SHRINKFILE (gm_data, 25600) When you recover a SQL database you'll find it will always create the same files, that's not to say you can't change the file paths. The best way to eliminate unwanted files and filegroups, is to: - create a new database with the desired files and filegroups. - create the tables without any Primary Keys, indexs, or other constraints. - Then insert the data in each table by writting a select statements. - then add back the remaining database objects. You can use SQL's scripting ability to generate scripts, but this will require some editing on your part. I've frequently edited scripts to control where tables and indexes will be creates. Note all stored procedures, triggers, and functions will be stored on the default filegroup. I will typically edit scripts to seperate them by database object, i.e. tables only, then primary keys, indexes, other constraints like foreign keys and check constraints, stored procedures, triggers, functions, database roles, grants, etc. I know this is a lot of work, but the final result will be you know where every object is stored in your database and you won't run into a table being stored across three different files on one or more logical drives.