You’d have to export to a standard file format, such as tab-delimited text or .SYLK or .XLS (Excel spreadsheet), or else set up your Access data as an ODBC source. Either way, all that comes over into Filemaker is the raw data, but that may not be as bad as you are probably initially inclined to think.
The noun that is known as a query in Access is more like a verb in Filemaker, known as a “Find”, and the results of an Access-style query (reports), if they take the simple form of simply displaying a list of the individual records that conform to the query parameters, constitute the “Found Set”. The interface (layout) in FileMaker is identical for data entry, doing the Find, and displaying the resulting found set, so to a major extent you don’t need to create and save permanent “queries” and “reports” in Filemaker the way you do in Access.
Not that you can’t: A Filemaker “Find” can be stored for replay by saving it as a Script:
Perform Find [restore, no dialog]
Sort [restore order, no dialog]}
More complex reports that you may have set up in Access, such as providing you with a sum total of the number movies within Category A (dramas), the movies in Category B (romantic comedies), and the movies in Category C (action flicks), and so on for a given query such as “show me all the post-1981 movies that contained Oscar nominees for ‘Best Actress’ and were not not produced by MGM/UA”, require a script that sorts the result of your query (find) and takes you to a different report layout that contains subsummary parts that summarize data within categories that you specify when sorted by that category (in this case, “Major Category”).
You can add or change fields or field names on the fly, you can add new reports at any time, and you can create portals that intrinsically subdivide your data and display it in a pre-sorted list (example: global field g_DirectorName, related to all records in the same file via local field DirectorName; put a portal on a layout, and put g_DirectorName at the top above the portal with a drop-down menu consisting of all values for the local field DirectorName. Then you just click into the field and select a given director’s name and instantly you are staring at a list of all films you’ve put in your database for whom that person is the director. You can easily set up similar self-join relationships for any other commonly used field; it’ll take you less than 5 minutes to duplicate an existing layout, duplicate the relationship and tie your search global to a different local field in the new rel, and double-click the portal and the fields you place in the portal and associate them with the new relationship.
If you ever want to restructure your database as a relational multi-table system, it is easy in FileMaker to abstract out a new file in which every record is a studio (and each film associated with a studio and, via that association, with all the information pertinent to it as a result of being produced by that studio, automatically available for display in whatever layouts you choose to design or print.
Essentially, Filemaker is pretty versatile and nimble and easy to work with. In my own workplace environment, nothing is used except Filemaker and SQL, the attitude being that if FileMaker won’t handle the job, nothing short of SQL is likely to be worth futzing with.
