none
Replica is inconsistent - ID 104 Details: The filename, directory name, or volume label syntax is incorrect (0x8007007B) RRS feed

  • General discussion

  • I want to share an issue resolution that I discovered in the hopes that it may help someone else with a similar problem.

    Backing up a SQL instance, two databases, model and msdb, were repeatedly reporting as inconsistent. Manual consistency checks had no effect. The error that repeatedly manifested was:

    An unexpected error occurred while the job was running. (ID 104 Details: The filename, directory name, or volume label syntax is incorrect (0x8007007B))

    I made a number of failed attempts to resolve the issue, essentially grasping at straws. Eventually I discovered that model and msdb were not in their default locations. While I did not think this would cause the error, I decided to move them back to the default location since nothing else worked. I ran the following query:

    SELECT name, physical_name AS CurrentLocation
    FROM sys.master_files
    WHERE database_id = DB_ID(N'model');
    GO
    

    The result was interesting:

    modeldev E:\MSSQL\Data/model.mdf
    modellog F:\MSSQL\Data/modellog.ldf

    Note the '/' preceding the file.

    I "moved" the files then, to change the '/' to a '\':

    USE master;
    GO
    ALTER DATABASE model 
    MODIFY FILE (NAME = modeldev, FILENAME = 'E:\MSSQL\Data\model.mdf');
    GO
    ALTER DATABASE model 
    MODIFY FILE (NAME = modellog, FILENAME = 'F:\MSSQL\Data\modellog.ldf');
    GO
    

    I went beck to DPM and started another consistency check and, lo and behold, the error went away. So, apparently SQL itself has no problem using a forward slash in a path, but DPM does.

    I hope this shortcuts a troubleshooting session for someone...

    Wednesday, June 27, 2012 3:00 PM

All replies

  • This post really saved my day, or rather week, had been looking for a solution to this problem alot!

    In my case it was even double slashes F:\SQLServer\MSSQL\DATA\/UserDatabase.mdf

    Someone had been running a bad installation script.

    Wednesday, September 5, 2012 12:22 PM