Hi I am told that filemaker follows an SQL standard.

We have filemaker pro 8.0 Can I access the database using activerecords or Rails? All I see mentioned is postgres, mysql, etc

I found it requires FileMaker Server Advanced 7.0, But the server advanced is 1400$ for education and I can't justify the cost right now.

My goal is to develop a small prototype using ruby: I want to program as little as possible in whatever database linguo the database uses.

You’ll have to forget about Filemaker. Since version 7, all external application access is limited only to Server Advanced (which is overly expensive), so you won’t be able to connect, I even think the Advanced (Developer version) is very limited so that it only can be used for testing purposes. ODBC was quite slow in Filemaker < version 7 but I’ve heard it’s better now.

We are still using Filemaker 6 for one of our applications and have written a custom application which synchronizes Filemaker through the Web Companion with a MySQL database. It provides two way synchronization every x minutes and works great. Wasn’t easy though. But now it allows us to have a web app running (for time registration) and take the Filemaker Server 5.5 offline for upgrades (which involve importing all data in your new version) and let personnel continue registering their jobs. By using the Web Companion (XML) and developing the synchronization app in REALbasic, we are able to have synchronization on all 3 platforms (Mac, Windows, Linux), unlike when using ODBC.

My advise: if you can avoid using Filemaker as a database for Rails apps, certainly do so. Filemaker is great for standalone RAD database development, but that’s where it stops.

Best regards

Peter De Berdt

Thanks, that makes sense. I will start with mysql since I have used it before. Then I will see if I need to try postgres.


anne001 wrote:

In that case, I would just use the SQLite that you get for free when you start any Rails project without specifying a database engine. That's going to be completely fine for any demo, I've even deployed with it for very low-volume sites.

To be clear, Rails does not require you to be database-specific unless you get out into the weeds of a project -- one that's "off the rails" by definition. You will specify the structure of your database using migrations, written in Ruby, and you'll be using those to talk (through the database adapter du jour) to your actual database engine. You're always working at least one level of abstraction away from the actual database engine in any case, because the adapters mediate requests (except for find_by_sql) and work around differences in primary key structures etc.

As far as I know, Filemaker can talk to SQL databases, and can do some import-y things in the reverse direction, but it's not specifically SQL inside. It has its own language and storage engine, unrelated to SQL, and can't be interrogated through SQL. This last part is from memory, I have not looked at the specs in at least a couple of years.