Sure we have hundreds of thousands of records in our tables, and even million in others...
Will FMP do some searching as fast as perhaps a SQL source on millions of records, probably not. However, with a properly structured file it should be way enough for regular use.
I second that, I'm running hundreds of databases, tens-of-thousands to hundreds-of-thousands of records. The speed issue only comes into play when using calculations that aggregate records from related tables/databases. At that point, a mySQL InnoDB table outperforms a similar FM table.
It's useful to note that design decisions can make a difference to scalability too. Something that works great for a few hundred records may turn into a dog with hundreds of thousands. I don't know if I can recall all of the issues with large record sets, but here are a few:
- Searches on unstored calcs
- Sorting of large record sets, especially over a WAN
- Sorted portals with large sets of related records
- Summary fields when dealing with large found sets
- Aggregate calcs on large related record sets
Thanks guys. Getting close on making a decision. There are only 7 or 8 tables, but I had bad experiences with Access scaling the way I wanted it to. Sounds like this may just work.
This is a related "scalability" issue that you may not have considered:
As your number of users increase, you can "scale up" filemaker to support larger numbers of simultaneous users in Filemaker much more smoothly than you can with MS Access for most situations. Once you have more users than Access can easily support, you have to switch to a completely different database app such as SQL Server and you have to convert your files to the new App's format. In filemaker pro you simply take your files, upload them to Filemaker server and keep on using them with little or no change to the files themselves.