Yes, I suppose one could build a database locally and link it to the databases on FileMaker Server, via External Data Sources. But this is for rare use (troubleshooting, immoral data viewing :-). Usually one just uses the Open Remote command, which opens the served file. It opens as if local (though slower). There is no need for any local FileMaker file; in normal client-server use there would not be.
[ ALWAYS use Open Remote to open hosted files. NEVER use OS File Sharing to open a remote FileMaker file (with rare exceptions).]
Sounds like you might be wanting to use data separation where the data tables reside in one File and the interfaces (layouts, scripts etc) reside in another. In Access, it is often suggested that the interface file be located on the client's machine for better responsiveness. You can also set it up this way with FileMaker, but you don't often see recomendations to do it this way unless you encounter significant performance delays due to an exceptionally slow network, or very high interface file overhead.
Instead, we usually describe placing both interface and data files on the server. Having a separate interface file makes it possible to deploy new versions of the system without importing data between files unless the update requires a change to the data file.
To set things up so that a layout (Form or report in Access) refers to an external table, do this:
Open Manage | Database | Relationships.
Click on the far left button at the bottom.
From the Data Source Drop down, select add FileMaker Data source and you'll be able to select a file (even one on the server) and a table within that file to link to. This puts a table occurrence "box" in your relationship graph that refers to the external table's records and you can now create a layout that refers to this new table occurrence just as though the table were defined inside the current file.
I'm impressed… 20 years of waging an internal Mac vs. PC war is the longest I've ever heard! I'm a Mac guy so I can say "welcome".
I would also recommend a data / interface separation model, where you keep the interface separate from the data. That's what I do; I've got 63 tables in my data file.
To counter one of Fenton's points, I would argue that there is a legitimate use for one local FileMaker file, commonly referred to as an "opener file." I still dislike FileMaker's Open Remote… interface (I have ever since I started back in the FileMaker 6 days), so I distribute a small opener file that allows my users to launch the solution with one click from the Mac OS X dock or Windows' start menu.
PS. as someone who has done some pretty intensive Access design work--including a lot of VB code and SQL queries, don't hesitate to post a question and couch in in Access terms familiar to you. I can "translate" the request and suggesst possible FileMaker equivalents to help you get over the initial startup hump.
Thanks Phil, this is what I was looking for. As you mention making upgrades with separate data tables is seamless. We also run 3 different data bases that share these table or some of them... Thanks again.
Yep, modular interface files is another use for the data-separation model. You have the option of locating them on the individual client machines or placing one copy of each on the server. With Filemaker, it's almost always easier to put them on the server.
You can use opener files like HazMatt describes so that different users can correctly open the interface file that's correct for them.