Serving secondary files through Main Menu File

[duncandawg]

I've been struggling with a solution which I'm building. It has a Main File which sort of acts like a Main Menu, and many secondary files which get called through scripted buttons. It was working great as I built it, but now that I'm ready to test it out on an FMP Server, it is giving me much grief.

First, the scripts which call other files seem to be looking locally on the client's machine. So I re-scripted almost all of the links I could find to open a specific (Hosted) file where I hard wired the IP it should look for to open the hosted file. This made me quite nervous, in that my iMac running the Server gets its IP Dynamically. However, I figured I'd sort out that problem later. Then I ran the server, and ran a client on another mac networked over ethernet to my iMac. Client behaved as it should and seemed to call the correct files where needed. So I left the Server running (IP address did not change) went to my office which runs Windows 98 machines, and attempted to log into my server app. All was good, until various scripts called for other files... it seemed to be opening (or rather trying to) other versions of these files... which were previous builds on my Windows machine. I double checked the script at the point where it should call the secondary file, and it was quite specific about the Hosted file (IP address and all).

Am I missing something here?? Which is the correct way to have my scripts open secondary files which are set to (Open Hidden Multi-User). These secondary files are in the same folder on the server as the main file.

I'm really scratching my head. If any one could shed some light for me, I'd be very pleased.

Thanks.

Duncandawg

[Kurt Knippel]

There are 2 ways to open served files. TCP/IP and Appletalk and that is IT.

Your server simply CANNOT be set to DHCP, it needs a static IP address in order to use TCP/IP properly.

You could use Appletalk, but then you would need to install an Appletalk client on all of the Windows workstations.

Put your files on the server (with its new, permanant, static IP address), open them all and make sure that all of the links are set correctly and then deploy the solution.

[duncandawg]

Kurt.... I understand of course if your IP is changing dynamically, how could the client stations possibly know where to look to open sserved files. However, for the purpose of testing my solution... I tried to connect while I knew what the present IP address was (in other words it was basically static for that day - as long as I didn't shut my server station down) but still I was having problems.

Of course I will serve my solution on a station with a static IP address. That's not my current problem.

[Kurt Knippel]

OK, so you setup your files over the course of a couple of weeks (for arguements sake) and in that time you had DHCP 15 diffent IP addresses (again for sake of arguement) now your soluion have multiple IP addresses scattered about in it, none of which are correct for your server.

Client connect over TCP/IP and cannot find the various IPs that you had used.

Get your files on the server ASAP and fix the links.

[duncandawg]

Kurt.

No, I did not build the solution over a couple of weeks on the server.

The whole time I was building the solution, I never once ran it on the server or had the files sitting in the same folder as the server.

It was only once I was ready to test my solution over IP that I moved the files to the server and ran it from the server.

All of the links were initially scripted to "Open File..."_"

When I tried the solution from my own machine... it worked no problem.

When I tried it over the server... the solution appeared to be looking on the client's machine for the files to open.

Then I went back to my solution, checked what my IP address was (which will not change until I shut down my machine all together) and changed all of the links to "Open File... "123.45.678.99... ___" whatever my IP address was. I tested this out on another machine (networked off of my server over ethernet) It worked just fine.

Without changing anything (not even my server's IP changed) I went immediately to my office to ttest out a Windows Client machine. It found the main file no problem, but again, it choked when looking for my secondary files.

I had this exact SAME problem without using the server, when I tried to network the solution from one Windows machine as a host (not server) and all the others in the same office were FileMaker Programs linking into the host.

I really don't believe the problem lies with the DHCP, because at the time I tested, my IP remained static the entire day of testing.

I'm convinced my problem lies somewhere in the way my scripts are calling these secondary files. Why does it work in some networked scenarios and not others?

Always I'm using IP networking only.

I'm so darn puzzled.

[Pupiweb]

That's expected behaviour, more or less

FileMaker searches very avidly for the files it needs, and uses the file name for the search so if you've copies left from development on your machine (even in the trash bin !) on or other machines FM will find and open them, making a mess ... (I've read reports of files created by other apps like PowerPoint opened by FM)

The solution is simply to throw away duplicate files (or compress them)

As a side note turn your TCP/IP protocol to none when you develop, else you'll embed the current IP in the scripts and the search for that IP will eventually slow down things

[Kurt Knippel]

Here is what you are doing.

Testing machine: IP 10.15.25.01 (for example)

All links get setup and tested and are working great.

Move files to server: IP 10.15.31.15 (for example).

Open on sample client. This client then looks to 10.15.25.01 for the files and does not find them, so it starts looking locally and does not find them, so it prompts you for the IP address.

You then pull the files off the server to another machine: IP 10.15.25.32 and proceede to fix the links.

All links get setup and tested and are working great.

Move files to server: IP 10.15.31.15 (for example).

Open on sample client. This client then looks to 10.15.25.01 for the files and does not find them, so it starts looking locally and does not find them, so it prompts you for the IP address.

and so on.

Once and for all. PUT THE FILES ON THE SERVER (with its own static IP address) and FIX ALL THE LINKS. Now they will all be pointing to the server's IP address and you will not have these problems.

[falkaholic]

The problem does not lie in DHCP. FileMaker searches your whole subnet for servers and makes it seem almost like AppleTalk. As well, if you server stays on the IP will not change.

Your problem could be one of these:

-You don't have the script of open via relative path.

-You changed the name of file and screwed up relations (make it prompt you for new location).

-The other files are not actually on the server.

[duncandawg]

Kurt,

You have now opened my eyes to this thing. you guys are right. I developed this a little at home (on my mac) and a little at work (on my PC) over the course of many weeks. Each time I would zip the folder, send it to my other workstation, unzip it, work on it some more and zip it and send it back and forth and so on.

Little did I know that the links were changing all this time.

I think I know what I need to do now, but I have one more question.

When I put it onto the machine it will be served from and place it in the same folder as the FMP Server Engine, do I then adjust all of my links to "Open_____"

where I simply select the secondary file (which rests in the same folder as the main menu file) or do I have to have the files running on the server, and click the "Hosts" button in my Open File Dialogue Window, then select specific IP Address and enter the address my server has, then select the secondary file.

I think by having a set of these files running on the server (actively being hosted) and choosing the specific IP address using the HOSTS Button, then I am sort of HARD WIRING my link to the secondary file. I'm guessing this would be the easiest way for the CLIENT machines then to find and open various secondary files. Is this correct?

BTW, thanks for being so patient with me while you have brought me to a new understanding - I hadn't realized what mess I was creating.

Duncandawg

[duncandawg]

OK... My boss splurged and bought a new PC (Pentium 4 something or other) for my database solution. I will run my solution on FM Server on this new machine. I spent hours and hours changing the names of my files and re-building many links, relationships, scripts... I'm almost finished the rebuild (which I have performed on this P4). Here's my next question:

As I test it out (running the server and connecting to my solution from another PC in the office) if I find any more missing links or problems which need to be addressed, how should I fix these? Do I go to the P4 and stop the server, then run FileMaker and open the files to make the changes, then start the server again?

Which is the proper way to make changes to this once it is on the machine which will serve it. I don't want to create any more problems for myself.

Thanks

[CyberSport]

Since you won't be opening the files ever on the same machine that filemaker server is running (at least, not at the same time that server is running), I would suggest that you fix all links on one of your clients that is connecting remotely via host. That way, all the links to other DBs, etc., will be done using the remote connection instead of trying to find a file locally.

Bevin

[duncandawg]

Thank you. So am I correct to understand then, that I cannot use the solutin myself as a user from the same machine which is serving it up? Not even if I log on to it using the open remote host method? If this is the case, I wish I hadn't given up my old workstation when my new one arrived!

[kennedy]

The recommendation is always that the server machine is wholly dedicated as a server machine. No users. No other responsibilities.

I rather am using my one power machine as both OS X server and FileMaker Server (though I do NOT let OS X server share the partition that holds FileMaker Server or the files it serves).

AND, I will periodically also use it for my own machine. However, if I needed to use it extensively, running lots of other apps, particularly MicroSloth apps, I would NOT do it on that machine.

So, I can report that it works fine to run FMP on the same machine as FMS... just make sure you open the files via remote hosts... don't just access the files directly!! And I've had no bad consequences as a result. But, it may have been wise to hang onto your old machine assuming you use your machine a lot.

[Kurt Knippel]

Good luck Kennedy. You are doing what is perhaps the worst possible thing for a server. The cost of repairing the eventual file/db corruptions will likely cost many times what a 2nd machine would have cost.

[kennedy]

Kurt, please explain. I've heard such assertions, but nobody has given them any substance.

Given I am running on a real OS (unix), I don't understand this assertion. If FMS is a worthy server, it MUST not be corruptible by other processes on the machine... unless the Darwin kernel misbehaves. Nothing has access to FMS's files; and nothing but the kernel can mess with the FMS process. Where's the big risk?

Now I can understand performance implications of running OS X Server and FMS on the same machine... but if FMS is so poorly written that some other processes running at the same time will cause it to corrupt its DB's, then I don't want to be running it anyway.

I don't run games or any Classic apps on the machine... nor anything that has any propensity to crash or cause the machine to lock-up. And nobody but me uses the machine.

I have yet to hear of *anybody* who has actually experienced any sort of conflict between OS X Server and FMS, other than it being slower than desired.

However, if you can explain to me why this could be an issue, I'll go buy the extra hardware. But without that, I am reluctant to burn a couple grand on an Xserver or to put FMS on an inferior iMac, just so its sitting all by itself.

Thanks for enlightening me.

[Anatoli]

IMHO it works or it doesn't. Everybody is against it but so far I didn't meet anyone with problem.

I wouldn't recommend it and at last 50% machines are not working anyway, because of TCP/IP problem, but seriously: did somebody lost data?

And Kennedy -- Server or client, iMac is sufficient for FM. Just with heavy load the server is too slow.