As noted elsethread, you can't import the data directly into ACCESS from
FileMaker. Exporting the data into a delimited textfile will then allow you
to import the text file into ACCESS tables.
ACCESS is a relational database, but I wouldn't agree that FileMaker is a
good relational database. ACCESS is much more powerful and capable than
FileMaker for database developing and capabilities. I've worked in both, and
it's much, much easier and faster to program/develop a database in ACCESS
than FileMaker.
Here is what I posted a few months ago to a poster's question about the
comparison between FM and ACCESS:
I have designed in FM Pro 7 and in ACCESS. There is no comparison between
the two -- they are completely different entities.
FM is not a database system -- it's a flat file system that lets you set up
some limited relationships. However, you cannot create or run queries, you
cannot write code to look up data and to manipulate layouts/data, the script
within it is similar to macros in ACCESS, but much less powerful, and you
cannot easily mix layout formats as needed. Not to mention that portals are
a simple version of subforms and subreports in ACCESS.
I admit that I have to think completely differently when developing in FM
("it is a flat file", "you cannot lookup an unrelated value from a table",
"you must store in the table all values that you think you will want to
display or use for relationships", "now which copy of the table is the one
that relates to this table -- oh yeah, it's the '_copy3' copy of that table,
not the table itself", "doggone it, how do I filter a table's contents to
just show me the record that matches values A and B from table 1 and values
C and D from table 2, and value 5 from table 3? oh yeah, I can't do that
directly unless I add more calculated fields to my table to store redundant
data", "why isn't that related value showing up in the layout? Oh yeah,
wrong related table copy, or oh yeah, that field only fills in if I edit the
data that was already entered", etc.)
My feeling is that FM is good for nondevelopers to set up and use, but
ACCESS allows development to be done in fractions of the time it takes to
try to figure out how to make FM do what I want it to do. Never mind that a
combo box (sorry, menu list or popup list in FM) cannot hide a column from
view, so I must show the values of both the bound field and the descriptive
field in the list, and I cannot include more than two fields in that list,
so if I want to display three things, I must create a calculated field in
the table to hold the concatenation of the two fields' values and then
display that concatenated value, and if I want to show six things, I need a
field that concatenates those six things into one field, etc.
And, unless you want to recreate all your relationships more than once, you
cannot separate the data tables from the "front end" layouts. You can put
all data into one FM file, and create relationships there. But if you then
want to use another file for the layouts and have that layout read the data
from the first file, you must again create the same relationships in that
second file that already exist in the first file. Thus, you end up with
everything being in one file, meaning that, if you ever need to change
something in the layouts, the entire database must be taken out of service
while you make and test the changes on that file. (Of course, if you want to
recreate the relationships between 80 tables (estimated 600 or so
relationships), not counting the copies of the tables (at least 3 - 5 copies
of each table so that you can set up the desired "non-queries" to get
related data) that also have relationships, then go for a front end file!)
It's taking me at least 4 times longer to develop an application in FM 7
(which, I'm told, is more powerful and flexible than FM 6) than it would in
ACCESS, and its functionality is frustratingly limited with respect to
display, data validation, data usage, updating tables (did I mention that
you can not run queries in FM, meaning no update queries and no append
queries and no delete queries?), rapid response to data entry needs, etc.
That's my somewhat biased yet experienced view ....
