I have an application that creates temporary aliases to several tables in a folder where there are hundreds of different folders (separate folder for each payroll and/or FLSA work period).

The data is stored on server with a path name like this: \\server\vol1\data\farstime\PPmmddyy where mmddyy is a date.

This same data is accessible from a client as x:\data (x: is mapped to the same unc path).

I had aliased some tables using the x: drive reference while running in development mode from a client.

Now when I try to run web engines from the server, I keep getting errors saying "open media failed on the following volumes… " and it lists out all the x: drive volumes either that I had previously done an alias to.

How do I permanently remove these x: drive volumes (which are not valid from the server) so that OI does not attempt to attach them?

Note that when I go into the Database Manager even on the client that has the X: drive mapped, these volumes do not show.

These volumes show in the SYSVOLUMES table.

When I do a DETACH_VOLUME, they temporarily go away from the SYSVOLUMES. However, when I exit and restart OI, they come back and show up again in the SYSVOLUMES table.

A listvolumes shows these problem volumes.

A listtables does not show any of the tables that are in these volumes.

How can I permanently remove these volumes?

What is the behavior of using an Alias in OI? Does it create a permanent reference to the volume and does OI then permanently and forever after try to attach each volume that had an aliased table?

I did look around and try to find a solution to my problem before posting here, so I apologize if this is something obvious and/or if anyone else has posted this and a solution has been provided.

Thank you for any help!

I found a way to fix this. I attached one table in each of these volumes from the Database Manager, then exited from Database Manager, then went back in to the Database Manager and did a "remove all tables from volume" for each.

After doing this all the bad volumes are gone and the volumes are not coming back even after my application establishes temporary pointers to them using the UNC reference.

It sounds like there was a table on the X: drive that is referenced in the DBT file. The DBT file is a list of tables and volumes to quickly attach automatically during launch.

Running DETACH_VOLUME only makes changes temporary, it doesn't save the current list of attached tables in the DBT file unless you run define_database().

At this point, I'd recommend you rebuild the DBT file to ensure everything is clean and up to date. Please follow the steps in this post.

View this thread on the Works forum...