6 Replies Latest reply on Nov 1, 2010 4:43 PM by philmodjunk

    Access user needs nube help with FM tables.



      Access user needs nube help with FM tables.


      After 20 years of debating and fighting it I finally broke down and switched over to Apple...  For this reason and a few others I need to convert my data base from Access to FM. 

      I’m having a problem getting my head around table location in FM.   I’m hoping someone can help me  with this.   Presently all my tables are located in their own Access data base located on the server ( just tables).  Each user PC houses it’s own Access data base,  in each the tables are linked to the server. No tables reside here only links.

      I can see how to import and link to external data in FM however i can get around not having a table in the actual data base.   It seems the only way I can get any forms to operate,  is to actually have the table right in the data base.   How do I link to external main tables?

        • 1. Re: Access user needs nube help with FM tables.

          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).]

          • 2. Re: Access user needs nube help with FM tables.

            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.

            • 3. Re: Access user needs nube help with FM tables.

              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.

              • 4. Re: Access user needs nube help with FM tables.

                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.

                • 5. Re: Access user needs nube help with FM tables.

                  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.  

                  • 6. Re: Access user needs nube help with FM tables.

                    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.