Greetings!

I recently moved an application from an old 7.2 OI to 9.2.

I created a location for the LH datafiles on the new system and attached them.

All works fine except when I delete a record in the file in which I am working, I get the FS109 error. The arror indicates the invalid volume directory name is "ARCSDATA" which is the name of one of the two attached data directories.

The file from which I am deleting records is not in that directory. Even if I detach the ARCSDATA volume I still get the FS109 error.

The record is deleted Ok, so not a real problem except I have 30,000 erroneous records to delete.

I wrote a little routine to do this, but the system error message comes up on each one.

So, want to suppress the system error message or fix the underlying cause.

There are no GFE's in ether of the two attached data volumes.

I have tried to replace the appname.dbt with a copy of sysprog.dbt.

( detach the volumes first, save the db, log out copy and rename the sysprog.dbt, log in and re attach)

same symptoms.

I bet someone knows how to tell me how to fix this.

Have fun!

Paxton

Are you using the Delete <tablehandle>, <key> Then Else statement to delete your records? If not, how are you deleting the records?

I think you were on the right track by replacing your appname.dbt file with sysprog.dbt but I suspect maybe your sysprog.dbt was also corrupt. Try getting a sysprog.dbt file from a fresh OI 9.x installation and repeating your steps.

Can you attach the tables and then delete the records from a fresh 9.x installation?

What MFS's are listed on the table you are trying to delete records from?

Thanks, Jared.

Just to "close the loop", Yes, I was using : "Delete <tablehandle>, <key> Then Else statement to delete "

Also, using TCL, (and assistant) got the same message.

Tried a SYSPROG.DBT from a known good installation, same results.

But, your comment about MFS's did it. I did have my own MFS on the table (used for audit trail on all the fields)

and after removing it, the deleterecord worked fine. So, I can delete the records and re-install the MFS.

The puzzle to me, is that the FS109 error referenced a different volume than the one where the file is located.

In this case:

c:\revsoft\hhdatabase\common is where the "PEOPLE" file is located

and the FS109 error referenced ARCSDATA which I presume means

c:\revsoft\hhdatabase\arcsdata

So, that fooled me.

Is the source of this 'issue' likely to be in the MFS itself? If so, I will examine it, though it is not a critical component in this application, now.

thanks and have fun!

Paxton

It's difficult to say why the MFS was causing this warning message without looking at the code but I speculate the MFS was triggering some operation like a system wide attach/detach that was encountering a problem on the ARCSDATA directory when it cycled through the list of volumes.

Maybe the MFS was encountering an error that should be cleared before the MFS ends. Without calling Set_Status(0) after the MFS maybe the BFS or the application was picking up a false error.

It should be easy enough to debug the MFS with the debugger to find the cause. If you managed to narrow down the problem code inside the MFS but can't explain why then please let me know and we can address it further.

View this thread on the forum...