Odd Message

[Oldfogey]

Does anyone have any idea what this message really means?

"FileMaker Pro cannot host files because another user is already hosting files using FileMaker Pro on this computer. Multi-user (shared) files will not be available to FileMaker Pro guests."

V6 on Citrix. Note that we do not use Server. There were two users sharing 4 files. The third, and subsequent, user(s) get this message. Oh, and multi-user files are available for some things.

Am not after a solution to the problem - the network+Citrix is a shambles. Desperately waiting for replacement gear/software. I'd just like to know what the message means. It is ambiguous.

[QuinTech]

Hi, Paul. This particular problem has been somewhat of a bugbear for us lately. I don't think we've found the best resolution, but the issue for us is probably the same one as you're seeing:

We have an opener file which looks across the network for a particular file. Works beautifully in multi-user situations. However, when we get into Citrix, what happens is that file stays open on the Citrix server, which we can think of as the user's local machine for this purpose. That file (the local file) is also hosted by the machine that has opened it, namely, the Citrix session of the first user to open it.

Now, here comes the second user, who opens a Citrix session, and proceeds to open that opener file. Because it's on the Citrix box, the second user is trying to open the very same file that is already open and hosted by the first user. It is as if he has used file sharing to find a file on a remote user's computer and tried to open it, which you're aware is a no-no.

Our resolution is this: If you have installed FMP from the OEM CD, you should have a registry key at [HKEY_LOCAL_MACHINESOFTWAREClassesFMP5]. This key enables a shortcut syntax which allows you to open files across the network without using a local opener file. The syntax is as follows:

"C:Program FilesFileMakerFileMaker Pro 6FileMaker Pro.exe" fmp5://192.168.x.x/RemoteFile.fp5

For more detail about this syntax, search for fmp5: and look at posts by DysktrL. I'd call him an expert on this.

Using the syntax above will, i think, resolve your issue.

HTH,

Jerry

[Oldfogey]

Thanks for that. Sorry to be so long getting back - trouble cutting down trees cos customer won't sharpen the axe.

No trace of that registry key. Do you mean OEM when you say OEM? I Am 99% certain that FMI don't offer OEMs here in the centre of the universe.

Anyway, I sort of figured the message meant what you describe. Still doesn't explain why we got it (repeatedly) after running for about two years!!

BUT you got my mind out of its rut (and rutting) and I thought I'd try the proper way to use FMP over a network. Most of our problems seem to have gone away.

I'm addng a bit more in case someone does a search on other weirds. One of our trigger happy employees managed to corrupt his timesheet so that it couldn't find a linked file ("can't find it . blah blah and it's busy and it's single user and blah blah".) We have multiple timesheets for employees and for special entries, like post, courier, etc. He seems to corrupt any file he touches!! He also managed to corrupt his girlfriend's timesheet! Am going to check next time I'm in there to see if I can see him in a mirror.

I am just bewildered at file corruption leading to a 'cannot find file' problem.

[Oldfogey]

Thanks for that. Sorry to be so long getting back - trouble cutting down trees cos customer won't sharpen the axe.

No trace of that registry key. Do you mean OEM when you say OEM? I Am 99% certain that FMI don't offer OEMs here in the centre of the universe.

Anyway, I sort of figured the message meant what you describe. Still doesn't explain why we got it (repeatedly) after running for about two years!!

BUT you got my mind out of its rut (and rutting) and I thought I'd try the proper way to use FMP over a network. Most of our problems seem to have gone away.

I'm addng a bit more in case someone does a search on other weirds. One of our trigger happy employees managed to corrupt his timesheet so that it couldn't find a linked file ("can't find it . blah blah and it's busy and it's single user and blah blah".) We have multiple timesheets for employees and for special entries, like post, courier, etc. He seems to corrupt any file he touches!! He also managed to corrupt his girlfriend's timesheet! Am going to check next time I'm in there to see if I can see him in a mirror.

I am just bewildered at file corruption leading to a 'cannot find file' problem.

[Oldfogey]

Thanks for that. Sorry to be so long getting back - trouble cutting down trees cos customer won't sharpen the axe.

No trace of that registry key. Do you mean OEM when you say OEM? I Am 99% certain that FMI don't offer OEMs here in the centre of the universe.

Anyway, I sort of figured the message meant what you describe. Still doesn't explain why we got it (repeatedly) after running for about two years!!

BUT you got my mind out of its rut (and rutting) and I thought I'd try the proper way to use FMP over a network. Most of our problems seem to have gone away.

I'm addng a bit more in case someone does a search on other weirds. One of our trigger happy employees managed to corrupt his timesheet so that it couldn't find a linked file ("can't find it . blah blah and it's busy and it's single user and blah blah".) We have multiple timesheets for employees and for special entries, like post, courier, etc. He seems to corrupt any file he touches!! He also managed to corrupt his girlfriend's timesheet! Am going to check next time I'm in there to see if I can see him in a mirror.

I am just bewildered at file corruption leading to a 'cannot find file' problem.

[QuinTech]

trouble cutting down trees cos customer won't sharpen the axe

I hear ya. I wish the software industry could survive without end-users. They only impede our progress.

No OEM CDs? Then how do you install? In any case, you should be able to create that key yourself. What do you mean by

the proper way to use FMP over a network

? I guess FMI's opinion may very well be that the syntax i described above is the proper way, but it seems to me that opener files are quite commonly used, at least by the crowd that hangs out here. It may be that opener files are not kosher vis-a-vis Citrix/Term Serv, though, and that's a consideration.

I am just bewildered at file corruption leading to a 'cannot find file' problem.

It makes perfect sense in a way. FM tries to open "FILENAME.fp5" and finds that it is corrupt. As a failsafe, it prompts the user to locate a non-corrupt version of that file. This, of course, leads to its own problems, as a user too smart for his own good may locate a similarly-named file somewhere else, but in an inappropriate location, and thus create misery. But it's still logical from a certain point of view.

J

[QuinTech]

trouble cutting down trees cos customer won't sharpen the axe

I hear ya. I wish the software industry could survive without end-users. They only impede our progress.

No OEM CDs? Then how do you install? In any case, you should be able to create that key yourself. What do you mean by

the proper way to use FMP over a network

? I guess FMI's opinion may very well be that the syntax i described above is the proper way, but it seems to me that opener files are quite commonly used, at least by the crowd that hangs out here. It may be that opener files are not kosher vis-a-vis Citrix/Term Serv, though, and that's a consideration.

I am just bewildered at file corruption leading to a 'cannot find file' problem.

It makes perfect sense in a way. FM tries to open "FILENAME.fp5" and finds that it is corrupt. As a failsafe, it prompts the user to locate a non-corrupt version of that file. This, of course, leads to its own problems, as a user too smart for his own good may locate a similarly-named file somewhere else, but in an inappropriate location, and thus create misery. But it's still logical from a certain point of view.

J

[QuinTech]

trouble cutting down trees cos customer won't sharpen the axe

I hear ya. I wish the software industry could survive without end-users. They only impede our progress.

No OEM CDs? Then how do you install? In any case, you should be able to create that key yourself. What do you mean by

the proper way to use FMP over a network

? I guess FMI's opinion may very well be that the syntax i described above is the proper way, but it seems to me that opener files are quite commonly used, at least by the crowd that hangs out here. It may be that opener files are not kosher vis-a-vis Citrix/Term Serv, though, and that's a consideration.

I am just bewildered at file corruption leading to a 'cannot find file' problem.

It makes perfect sense in a way. FM tries to open "FILENAME.fp5" and finds that it is corrupt. As a failsafe, it prompts the user to locate a non-corrupt version of that file. This, of course, leads to its own problems, as a user too smart for his own good may locate a similarly-named file somewhere else, but in an inappropriate location, and thus create misery. But it's still logical from a certain point of view.

J

[DykstrL]

I'm confused why you are having problems with Citrix/Terminal Server and Opener files, Jerry. We use opener files that are on the desktop for all users that log onto the server.

If the opener file is configured correctly, subsequent users should not get a "file open..." error. Make sure that the next script step is to close itself right after opening the server file and to have Allow user abort Off.

Thought I'd point out the obvious...

[DykstrL]

I'm confused why you are having problems with Citrix/Terminal Server and Opener files, Jerry. We use opener files that are on the desktop for all users that log onto the server.

If the opener file is configured correctly, subsequent users should not get a "file open..." error. Make sure that the next script step is to close itself right after opening the server file and to have Allow user abort Off.

Thought I'd point out the obvious...

[DykstrL]

I'm confused why you are having problems with Citrix/Terminal Server and Opener files, Jerry. We use opener files that are on the desktop for all users that log onto the server.

If the opener file is configured correctly, subsequent users should not get a "file open..." error. Make sure that the next script step is to close itself right after opening the server file and to have Allow user abort Off.

Thought I'd point out the obvious...

[QuinTech]

Make sure that the next script step is to close itself

We'd been in the habit of doing that, but at some point it stopped working for some clients. It seems that the file references were getting screwed, for some reason.

When we determined that, and armed with the knowledge (learned from you a while back) regarding the fmp5://192.168.x.x/filename.fp5 syntax, we figured the cleanest solution would be to bypass the local opener file completely and use the URL syntax. Our opener files serve no purpose other than to open the remotely hosted files, so there is no difference in function.

While i have your ear, what do you know about Winsock error 10048? Apparently one of our Citrix-based clients gets that frequently. It appears to occur after they have launched the local (Citrix server) opener file and the remote file that is opened sends back the message to the local machine to close the opener file. Let me rephrase that:

On the Citrix server, there is a file called StartRem.usr that is our usual opener file. On the FM server, there is a file that is opened by StartRem.usr. Its name is Opener.usr. Opener.usr sends the message back to the Citrix server to close StartRem.usr. It appears that this is the point at which the user gets Winsock error 10048. Could this be another symptom of the file reference problem? That is, maybe Opener.usr is trying to close C:thisFolderStartRem.usr but the file is actually at C:thatFolderStartRem.usr?

Not a big issue since, as i said, we avoided it by skipping the local opener file using the URL syntax. But i am curious.

J

[QuinTech]

Make sure that the next script step is to close itself

We'd been in the habit of doing that, but at some point it stopped working for some clients. It seems that the file references were getting screwed, for some reason.

When we determined that, and armed with the knowledge (learned from you a while back) regarding the fmp5://192.168.x.x/filename.fp5 syntax, we figured the cleanest solution would be to bypass the local opener file completely and use the URL syntax. Our opener files serve no purpose other than to open the remotely hosted files, so there is no difference in function.

While i have your ear, what do you know about Winsock error 10048? Apparently one of our Citrix-based clients gets that frequently. It appears to occur after they have launched the local (Citrix server) opener file and the remote file that is opened sends back the message to the local machine to close the opener file. Let me rephrase that:

On the Citrix server, there is a file called StartRem.usr that is our usual opener file. On the FM server, there is a file that is opened by StartRem.usr. Its name is Opener.usr. Opener.usr sends the message back to the Citrix server to close StartRem.usr. It appears that this is the point at which the user gets Winsock error 10048. Could this be another symptom of the file reference problem? That is, maybe Opener.usr is trying to close C:thisFolderStartRem.usr but the file is actually at C:thatFolderStartRem.usr?

Not a big issue since, as i said, we avoided it by skipping the local opener file using the URL syntax. But i am curious.

J

[QuinTech]

Make sure that the next script step is to close itself

We'd been in the habit of doing that, but at some point it stopped working for some clients. It seems that the file references were getting screwed, for some reason.

When we determined that, and armed with the knowledge (learned from you a while back) regarding the fmp5://192.168.x.x/filename.fp5 syntax, we figured the cleanest solution would be to bypass the local opener file completely and use the URL syntax. Our opener files serve no purpose other than to open the remotely hosted files, so there is no difference in function.

While i have your ear, what do you know about Winsock error 10048? Apparently one of our Citrix-based clients gets that frequently. It appears to occur after they have launched the local (Citrix server) opener file and the remote file that is opened sends back the message to the local machine to close the opener file. Let me rephrase that:

On the Citrix server, there is a file called StartRem.usr that is our usual opener file. On the FM server, there is a file that is opened by StartRem.usr. Its name is Opener.usr. Opener.usr sends the message back to the Citrix server to close StartRem.usr. It appears that this is the point at which the user gets Winsock error 10048. Could this be another symptom of the file reference problem? That is, maybe Opener.usr is trying to close C:thisFolderStartRem.usr but the file is actually at C:thatFolderStartRem.usr?

Not a big issue since, as i said, we avoided it by skipping the local opener file using the URL syntax. But i am curious.

J

[DykstrL]

I used to have that same problem - I found out I had some 'hidden' Halt Script steps in the open script. I used to use Halt Script all the time, but I now use Exit Script instead, unless I specifically want to halt all scripts at that point.

As to the winsock error, the "address" they refer to, typically refers to the local "socket name", which is made up of the 3-tuple: protocol, port-number and IP address. It generally means that the address is already in use on that machine, which confuses me because Citrix/TS is supposed to resolve that, unless the close step is going back to the Citrix/TS server and cannot be resolved to the specific user.

[DykstrL]

I used to have that same problem - I found out I had some 'hidden' Halt Script steps in the open script. I used to use Halt Script all the time, but I now use Exit Script instead, unless I specifically want to halt all scripts at that point.

As to the winsock error, the "address" they refer to, typically refers to the local "socket name", which is made up of the 3-tuple: protocol, port-number and IP address. It generally means that the address is already in use on that machine, which confuses me because Citrix/TS is supposed to resolve that, unless the close step is going back to the Citrix/TS server and cannot be resolved to the specific user.

[DykstrL]

I used to have that same problem - I found out I had some 'hidden' Halt Script steps in the open script. I used to use Halt Script all the time, but I now use Exit Script instead, unless I specifically want to halt all scripts at that point.

As to the winsock error, the "address" they refer to, typically refers to the local "socket name", which is made up of the 3-tuple: protocol, port-number and IP address. It generally means that the address is already in use on that machine, which confuses me because Citrix/TS is supposed to resolve that, unless the close step is going back to the Citrix/TS server and cannot be resolved to the specific user.

[Oldfogey]

The 'proper' way? We had the DB on a shared volume. It used to work fine with V3 but went berserk when we upgraded to V6. The bloke who installed Citrix did something funny to get V3 to work but I could not get him to tell us what he did. Both FMI and the Citrix consultants were useless.

I finaly gave up and moved the whole DB to a non-shared volume. Works like a charm - sort of. We have an opener script in the main file. Causes no problems so far.

We have a language problem (I do wish you Yanks would learn English.) 'OEM' refers to the copies of software that are distributed with new hardware - very cheap. This is how MS get MS Office (plus Access) everywhere. OEMs are usually just CD-ROMs - no manuals or pretty box.

Customer is a peak body for associations. Handle membership for about half a dozen of them. Membership is a totally enclosed different DB for each association. Single user. My trigger happy friend managed to get the '..cannot find MembCodes.fp5 ... blah, blah, blah'. HOW?!?!?!?!? One of his associates has christened him anti-Midas.

Re corruption and losing files, I can understand FMP finding a corrupt file and getting confused but the file getting 'lost' is not corrupt; it is the users' individual files that are corrupt.

The moral here for me (which I originally learnt before man landed on the moon but forgot) is 'try the simple things first'. Like doing the basics.

[Oldfogey]

The 'proper' way? We had the DB on a shared volume. It used to work fine with V3 but went berserk when we upgraded to V6. The bloke who installed Citrix did something funny to get V3 to work but I could not get him to tell us what he did. Both FMI and the Citrix consultants were useless.

I finaly gave up and moved the whole DB to a non-shared volume. Works like a charm - sort of. We have an opener script in the main file. Causes no problems so far.

We have a language problem (I do wish you Yanks would learn English.) 'OEM' refers to the copies of software that are distributed with new hardware - very cheap. This is how MS get MS Office (plus Access) everywhere. OEMs are usually just CD-ROMs - no manuals or pretty box.

Customer is a peak body for associations. Handle membership for about half a dozen of them. Membership is a totally enclosed different DB for each association. Single user. My trigger happy friend managed to get the '..cannot find MembCodes.fp5 ... blah, blah, blah'. HOW?!?!?!?!? One of his associates has christened him anti-Midas.

Re corruption and losing files, I can understand FMP finding a corrupt file and getting confused but the file getting 'lost' is not corrupt; it is the users' individual files that are corrupt.

The moral here for me (which I originally learnt before man landed on the moon but forgot) is 'try the simple things first'. Like doing the basics.

[Oldfogey]

The 'proper' way? We had the DB on a shared volume. It used to work fine with V3 but went berserk when we upgraded to V6. The bloke who installed Citrix did something funny to get V3 to work but I could not get him to tell us what he did. Both FMI and the Citrix consultants were useless.

I finaly gave up and moved the whole DB to a non-shared volume. Works like a charm - sort of. We have an opener script in the main file. Causes no problems so far.

We have a language problem (I do wish you Yanks would learn English.) 'OEM' refers to the copies of software that are distributed with new hardware - very cheap. This is how MS get MS Office (plus Access) everywhere. OEMs are usually just CD-ROMs - no manuals or pretty box.

Customer is a peak body for associations. Handle membership for about half a dozen of them. Membership is a totally enclosed different DB for each association. Single user. My trigger happy friend managed to get the '..cannot find MembCodes.fp5 ... blah, blah, blah'. HOW?!?!?!?!? One of his associates has christened him anti-Midas.

Re corruption and losing files, I can understand FMP finding a corrupt file and getting confused but the file getting 'lost' is not corrupt; it is the users' individual files that are corrupt.

The moral here for me (which I originally learnt before man landed on the moon but forgot) is 'try the simple things first'. Like doing the basics.

[QuinTech]

Paul: Don't spit the dummy. (See, i DO know English. ) I thought OEM also referred to any manufacturer-issued material, as opposed to software repackaged under a licensing agreement.

Since GW Bush wants to send another manned flight to the moon, maybe now is a good time for you to have re-learned that lesson.

DysktrL: "unless the close step is going back to the Citrix/TS server and cannot be resolved to the specific user" -- do you think this might happen if User1 on the Citrix server has the local file open, and then User2 runs the script that tries to close that file? Maybe the second session's attempt to close the file is fuddled by the first session's insistence on keeping the file open, somehow?

[QuinTech]

Paul: Don't spit the dummy. (See, i DO know English. ) I thought OEM also referred to any manufacturer-issued material, as opposed to software repackaged under a licensing agreement.

Since GW Bush wants to send another manned flight to the moon, maybe now is a good time for you to have re-learned that lesson.

DysktrL: "unless the close step is going back to the Citrix/TS server and cannot be resolved to the specific user" -- do you think this might happen if User1 on the Citrix server has the local file open, and then User2 runs the script that tries to close that file? Maybe the second session's attempt to close the file is fuddled by the first session's insistence on keeping the file open, somehow?

[QuinTech]

Paul: Don't spit the dummy. (See, i DO know English. ) I thought OEM also referred to any manufacturer-issued material, as opposed to software repackaged under a licensing agreement.

Since GW Bush wants to send another manned flight to the moon, maybe now is a good time for you to have re-learned that lesson.

DysktrL: "unless the close step is going back to the Citrix/TS server and cannot be resolved to the specific user" -- do you think this might happen if User1 on the Citrix server has the local file open, and then User2 runs the script that tries to close that file? Maybe the second session's attempt to close the file is fuddled by the first session's insistence on keeping the file open, somehow?

[DykstrL]

<b>Jerry</b> I have been thinking about that... It doesn't make sense now. The server actions would be based on the client environment. You may be on the right track. I wonder if you added a "Set error capture [on] to the open script so any errors when trying to close it are ignored?? ... I gotta do some more testing.

...another fine quandry you've gotten me into!

<b>Oldfogey</b> From your last post, I get the impression that you are NOT sharing the files via FM Server?

I think that using a FM server for sharing FM files on a Citrix/TS is an absolute must! I have heard of sharing files on the Citrix/TS, but do not allow sharing - only one user is allowed at a time.

[DykstrL]

<b>Jerry</b> I have been thinking about that... It doesn't make sense now. The server actions would be based on the client environment. You may be on the right track. I wonder if you added a "Set error capture [on] to the open script so any errors when trying to close it are ignored?? ... I gotta do some more testing.

...another fine quandry you've gotten me into!

<b>Oldfogey</b> From your last post, I get the impression that you are NOT sharing the files via FM Server?

I think that using a FM server for sharing FM files on a Citrix/TS is an absolute must! I have heard of sharing files on the Citrix/TS, but do not allow sharing - only one user is allowed at a time.

[DykstrL]

<b>Jerry</b> I have been thinking about that... It doesn't make sense now. The server actions would be based on the client environment. You may be on the right track. I wonder if you added a "Set error capture [on] to the open script so any errors when trying to close it are ignored?? ... I gotta do some more testing.

...another fine quandry you've gotten me into!

<b>Oldfogey</b> From your last post, I get the impression that you are NOT sharing the files via FM Server?

I think that using a FM server for sharing FM files on a Citrix/TS is an absolute must! I have heard of sharing files on the Citrix/TS, but do not allow sharing - only one user is allowed at a time.

[QuinTech]

another fine quandry you've gotten me into!

That's what i do best!

I'm going to take your advice and use error capturing within FM to see if i can get a clearer picture. Also, this is all coming to me third-hand, so i may have mis-described something (although the first and second hands are reliable to repeat good information, i fear i may have missed some details).

J

[QuinTech]

another fine quandry you've gotten me into!

That's what i do best!

I'm going to take your advice and use error capturing within FM to see if i can get a clearer picture. Also, this is all coming to me third-hand, so i may have mis-described something (although the first and second hands are reliable to repeat good information, i fear i may have missed some details).

J

[QuinTech]

another fine quandry you've gotten me into!

That's what i do best!

I'm going to take your advice and use error capturing within FM to see if i can get a clearer picture. Also, this is all coming to me third-hand, so i may have mis-described something (although the first and second hands are reliable to repeat good information, i fear i may have missed some details).

J

[Oldfogey]

I think that using a FM server for sharing FM files on a Citrix/TS is an absolute must! I have heard of sharing files on the Citrix/TS, but do not allow sharing - only one user is allowed at a time

Yes, in fact FMI told me that FMP is not supported under Citrix without Server but I have never found this documented anywhere. I know the general consensus is that you should have Server but we have probably the world's smallest Citrix installation - a server plus six workstations, with rarely more than 2-3 active and almost nil activity on FMP.

We actually installed Server but got nowhere. Problem is partly that our Citrix/WinFrame is older than I am.

We seem to be OK now so I am leaving well alone - even if it shouldn't work. V3 was fine without Server, if only I knew what the original installer did. Hopefully we'll get some replacement hardware and software soon and Citrix will be behind us.

[Oldfogey]

I think that using a FM server for sharing FM files on a Citrix/TS is an absolute must! I have heard of sharing files on the Citrix/TS, but do not allow sharing - only one user is allowed at a time

Yes, in fact FMI told me that FMP is not supported under Citrix without Server but I have never found this documented anywhere. I know the general consensus is that you should have Server but we have probably the world's smallest Citrix installation - a server plus six workstations, with rarely more than 2-3 active and almost nil activity on FMP.

We actually installed Server but got nowhere. Problem is partly that our Citrix/WinFrame is older than I am.

We seem to be OK now so I am leaving well alone - even if it shouldn't work. V3 was fine without Server, if only I knew what the original installer did. Hopefully we'll get some replacement hardware and software soon and Citrix will be behind us.

[Oldfogey]

I think that using a FM server for sharing FM files on a Citrix/TS is an absolute must! I have heard of sharing files on the Citrix/TS, but do not allow sharing - only one user is allowed at a time

Yes, in fact FMI told me that FMP is not supported under Citrix without Server but I have never found this documented anywhere. I know the general consensus is that you should have Server but we have probably the world's smallest Citrix installation - a server plus six workstations, with rarely more than 2-3 active and almost nil activity on FMP.

We actually installed Server but got nowhere. Problem is partly that our Citrix/WinFrame is older than I am.

We seem to be OK now so I am leaving well alone - even if it shouldn't work. V3 was fine without Server, if only I knew what the original installer did. Hopefully we'll get some replacement hardware and software soon and Citrix will be behind us.