We've had the following setup without any problems for quite some time now:

Local network filemaker server 5.5 running several database files, 1 called
for example x.fp5

Remote network filemaker server 5.5 running several database files,
including a different file called the same x.fp5.

From our lan I'm connecting to external host (entered ip address) and
double-clciked the remote x.fp5. However, it opens up the local x.fp5, but
we can't work out why - its never happened before...

To add a tad of confusion, there are remote users logging in from the same
remote network where the x.fp5 is being hosted from connecting to our local
x.fp5.  However, there is only one x.fp5 in their remotely hosted files
list. What's going on? Any ideas? We're baffled...

"nospam" <nospam@nospam.com> wrote in message
news:415a8d0e$0$1204$afc38c87@news.easynet.co.uk...
> We've had the following setup without any problems for quite some time
now:
>
> Local network filemaker server 5.5 running several database files, 1
called
> for example x.fp5
>
> Remote network filemaker server 5.5 running several database files,
> including a different file called the same x.fp5.
>
> From our lan I'm connecting to external host (entered ip address) and
> double-clciked the remote x.fp5. However, it opens up the local x.fp5, but
> we can't work out why - its never happened before...
>
> To add a tad of confusion, there are remote users logging in from the same
> remote network where the x.fp5 is being hosted from connecting to our
local
> x.fp5.  However, there is only one x.fp5 in their remotely hosted files
> list. What's going on? Any ideas? We're baffled...

You've hit a known issue - If for any reason FileMaker has trouble making
the desired connection, it will search for the file *name* anywhere it can
reach, and if it finds an open file of the same name, it will use it, and
then probably remember that path as well.

Never have 2 files with the same name available for use. And yes, this means
renaming one of the files to something else.

Cheers

Webko

> You've hit a known issue - If for any reason FileMaker has trouble making
> the desired connection

But the files were listed on the remote server - I even managed to open up
one of the other remote files (not with the same name) - so how can the
connectivity have been a problem?

>, it will search for the file *name* anywhere it can
> reach, and if it finds an open file of the same name, it will use it, and
> then probably remember that path as well.

I've worked on these files locally and remotely before and have never
encountered this issue before - this seems to be a different kind of
problem...

> Never have 2 files with the same name available for use. And yes, this
means
> renaming one of the files to something else.

Even when we have no control over the remote files named the same? That's
not a viable way of working.

In the end, we logged in and saw who was connected to our file x.fp5, we
noticed there was a remote user from the end with the x.fp5 we wanted to
connect to. Even though there was only one x.fp5 showing at the other end,
it miraculously worked when the remote user to our x.fp5 disconnected.

Thus I think that if site A and site B both host different files both named
x.fp5 when a user from site A connects to site B's x.fp5 it screws up site B
user's connection to site A's x.fp5. How ridiculous! Locally, I can
understand - don't have a file called x.fp5 on your desktop if you have
x.fp5 on the server - but you have no control over other remote files'
filenames. You can't possibly always name files in advance not to clash with
other developers' files or when projects merge, etc.

If the relationships and/or other file references were created locally, 
then FMP will first try to resolve those references locally before 
looking on the server.

One thing that always works for me -- at least on a Windows machine -- 
is to make sure that when you go to File > Open, you CANNOT see any of 
the FM5 files that might be called.  But this is only true if the 
references were saved with 'relative path only'.

The best solution is not to make those files available to any place that 
FMP can see.  Or else in FM7, this is no longer an issue.

nospam wrote:
>>You've hit a known issue - If for any reason FileMaker has trouble making
>>the desired connection
> 
> 
> But the files were listed on the remote server - I even managed to open up
> one of the other remote files (not with the same name) - so how can the
> connectivity have been a problem?
> 
> 
>>, it will search for the file *name* anywhere it can
>>reach, and if it finds an open file of the same name, it will use it, and
>>then probably remember that path as well.
> 
> 
> I've worked on these files locally and remotely before and have never
> encountered this issue before - this seems to be a different kind of
> problem...
> 
> 
>>Never have 2 files with the same name available for use. And yes, this
> 
> means
> 
>>renaming one of the files to something else.
> 
> 
> Even when we have no control over the remote files named the same? That's
> not a viable way of working.
> 
> In the end, we logged in and saw who was connected to our file x.fp5, we
> noticed there was a remote user from the end with the x.fp5 we wanted to
> connect to. Even though there was only one x.fp5 showing at the other end,
> it miraculously worked when the remote user to our x.fp5 disconnected.
> 
> Thus I think that if site A and site B both host different files both named
> x.fp5 when a user from site A connects to site B's x.fp5 it screws up site B
> user's connection to site A's x.fp5. How ridiculous! Locally, I can
> understand - don't have a file called x.fp5 on your desktop if you have
> x.fp5 on the server - but you have no control over other remote files'
> filenames. You can't possibly always name files in advance not to clash with
> other developers' files or when projects merge, etc.
> 
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California

FileMaker 7 Certified Developer
Associate Member, FileMaker Solutions Alliance

> If the relationships and/or other file references were created locally,
> then FMP will first try to resolve those references locally before
> looking on the server.

I know that this eccentric piece of filemaker behaviour is the case, but am
confused as to why the remote files have always opened first, except on this
occasion (where the remote site's user was logged into the same named x.fp5
on our local network and no structural work has been carried on the files
recently). I would never normally open up x.fp5 on my server if I knew it
was also on my desktop, because the chances are it'll open up my desktop
copy.

> The best solution is not to make those files available to any place that
> FMP can see.  Or else in FM7, this is no longer an issue.

Well, its not a realistic way of working as I've said before, to make sure
there are no other files called the same in different sites, which may well
be out of your control...

Anyway, its pretty crap when you go to File > Open REMOTE and choose the
REMOTE file and it still opens up a more local copy. What is the point of
opening REMOTE on a specific IP if its not necessarily going to open that
file. They might as well change the option to: "Attempt to open the remote
file you want, but we might open up a local version of it instead, who
knows...".

nospam wrote:
>>The best solution is not to make those files available to any place that
>>FMP can see.  Or else in FM7, this is no longer an issue.
> Well, its not a realistic way of working as I've said before, to make sure
> there are no other files called the same in different sites, which may well
> be out of your control...

You won't be able to make sure what the other folks call the file names, but on your copy, 
you can, right? And also, is it necessary to have the other folks be saving database files 
on their harddrive in the first place? Maybe the way that they do it can be changed or 
simplified via a walkthrough script or something. Or maybe it's possible to talk to 
whomever is in charge of the other files to have everyone agree on a naming scheme? You 
only have to do it once(and when new files get made).

If the problem hasn't happened before, I wonder if your FMP server is going barmy? I don't 
need to use it, so I wouldn't be able to work it out, but I thought I did read some posts 
about making sure that FMP server goes opens the right files 'and stuff'. :)

> Anyway, its pretty crap when you go to File > Open REMOTE and choose the
> REMOTE file and it still opens up a more local copy. What is the point of
> opening REMOTE on a specific IP if its not necessarily going to open that
> file. 

That's never happened to me, if I do it manually, instead of script. And if via script it 
got screwed up, it stays screwed up until I do it physically, like Howard said.
In fact, filemaker is so orney in that if it can't find the remote, or similar named file, 
it grabs any file that is *.fmp. I have a file called "Current", and once (or twice) it 
was closed, and someone tried to remote link to it, and instead the local "Archive C" was 
picked up. After I switched the name to "Old Never Use", it grabbed that one. :)

I finally had to make a default layout on the archives with a textbox instructions on how 
to 1)call in to get someone to open the remote and 2)open remote file.

> They might as well change the option to: "Attempt to open the remote
> file you want, but we might open up a local version of it instead, who
> knows...".

"0010IF0010010IT001010FEELS0010GOOD,00101DO10010100IT!00101010"
-- 
"... respect, all good works are not done by only good folk ..."
    -till next time, Jameson Stalanthas Yu -x- <<poetry.dolphins-cove.com>>
        consul@INVALIDdolphins-cove.com ((remove the INVALID to email))