Hi All

I am confused and unfortunately a search for FS109 didn't really seem to lighten that confusion, so I am after suggestions

We attach our tables upon logging into our application so that during development we can test against different clients data.

One set of tables that we were previously using regularly have just started to not attach. No changes have occurred that we can think of.

The scenario is as follows.

Directory structure

T:\clients\client1\multipledirs_with_tables

T:\clients\client2\multipledirs_with_tables

T:\clients\client3\multipledirs_with_tables

3 Different versions of application

1 Local - attaches all 3 clients above without problems

1 Network drive (P) - attaches all 3 clients above without problems

1 Network drive (T) - attaches 2 clients without problems, client3 does not attach. Investigation of error status returns FS109:@vm:path

Symptoms reproducible on multiple workstations. P and T different mappings but same server

I originally posted this on the works section about a week ago and Oystein did well to respond the same day with some suggestions. Unfortunately, there was nothing conclusive and my response to Oystein has not received any replies. The core of my response is below for the wider community to read.

I don't believe there is anything making the folder inaccessible. If there was, I would expect to not be able to attach the data from any version of the application. However I can do this from all other copies, both local and network. As for an error in the volume name, again the volume name is the same in all other copies of the application. The Attach_Table function is using an absolute path but any thoughts on why that would matter on just the one application, and why now when it has been working successfully for at least 12 months? The last suggestion was a clue I had tried for myself and unfortunately, the correct path is being returned. Here is some new details that may help the more knowledgable than myself out there. We have some new data from a different client that we have applied the same process to. The attaching of this volume is providing the same error message but only intermittantly. I mean that sometimes when we detach one volume and attach the new volume, it works as expected. Other times it produces the FS109 error. If we get the error we have to shut down the application and log back in, in order to be able to get to that data. With the volume mentioned in my original posting, we get the FS109 every time.

Now that a week or so has passed, the problem is beginning to spread.

A few more volumes that were previously unaffected are now beginning to display the same symptoms intermittently. The symptoms being sometimes they attach, sometimes they don't. If they don't, we simply close the application, log back in and voila attach they will.

Now that my novel is finished, any thoughts anyone????

Mark

I don't think I have the answer but, as we've done fairly similar things, maybe the following might suggest clues…

From REVERROR.DAT, FS109 results from the attach name being an "invalid volume directory label".

Does the attach work from the system editor? Does it work from ARev TCL (if you have it available)?

Having had problems (probably our fault!) with keeping DBT files up to date at users' sites with an app which undergoes quite frequent updates, we now use DBT files just for basic system files and attach app-specific and data files dynamically.

We also have installations which use several multiply-configured sets of data. This the user can switch between them. This is done by detaching the current volume and attaching the next volume selected.

The problems we had in getting this working were :-

1) System updates updated the DBT file and the attaches then didn't work. Solution: alter RDKModuleInstall to make DBT updates optional.

2) Failure to detach the current volume before attaching the next.

Once solved it's now worked fine for several years.

Good luck!

We've seen this happen when the files are being opened exclusive on the server, different instances of the NT Service are loaded with the same serial number or people are accessing the files through different network drivers.

The Sprezzatura Group

World Leaders in all things RevSoft

Looks like you win again Sprezz

Network version was using byte-range locking Multi-User Driver Ver. 2.0c

Local version was using All Networks Driver ver. 2.1

Changed the local version and touchwood, it seems to be working ok.

Still leaves me wondering why it has only decided recently that it didn't want to work. However, if it keeps working now, I'm happy.

Thanks

Mark

View this thread on the forum...