databasename_indx.ndf file not referenced but can't delete
The information about files has somehow got out of synch between the master database and the CallAccounting database.

So I suppose there are two possibilities.


The file information was erroneously removed from the system tables in the user database.
The file row should have been removed from the master database but for some reason wasn't (or maybe master was restored from backup at some point which brought back in information about a previously deleted file).


The second one seems much more likely as I'm pretty sure that in the first case you would be encountering a bunch of other errors when queries tried to access data in that file.

First run DBCC CHECKDB and see if that tells you anything useful.

If it doesn't you could use DBCC IND to dump out information about all relevant objects to check that nothing appears to be using that file.

SET NOCOUNT ON;

CREATE TABLE #DBCCIND   (
     PageFID         TINYINT,
     PagePID         INT,
     IAMFID          TINYINT,
     IAMPID          INT,
     ObjectID        INT,
     IndexID         TINYINT,
     PageType        TINYINT,
     IndexLevel      TINYINT,
     NextPageFID     TINYINT,
     NextPagePID     INT,
     PrevPageFID     TINYINT,
     PrevPagePID     INT
  ); 


DECLARE @id varchar(10)

DECLARE @C1 AS CURSOR;
SET @C1 = CURSOR FAST_FORWARD FOR SELECT DISTINCT id
FROM   sysindexes
OPEN @C1;
FETCH NEXT FROM @C1 INTO @id;
WHILE @@FETCH_STATUS = 0
BEGIN

INSERT INTO #DBCCIND
    EXEC('DBCC IND (0, ' + @id + ', -1) WITH NO_INFOMSGS')
  FETCH NEXT FROM @C1 INTO @id ;
END

SELECT IAMFID AS FileId
FROM #DBCCIND
UNION 
SELECT NextPageFID
FROM #DBCCIND
UNION 
SELECT PrevPageFID
FROM #DBCCIND

DROP TABLE #DBCCIND


If you do see FileID of 3 returned then something is definitely using it.

If you don't I'd probably try attaching (copies of) just the mdf and ldf to another instance and test to see it all works correctly (with CHECKDB and selecting all rows from all tables).

If all of this works without error then it is possibly OK to backup everything then go ahead and delete that row referencing the file from master..sysaltfiles (will need ad hoc updates to system catalogs enabled).

I, of course, accept no liability if this all goes horribly wrong however!