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 http://rubyforge.org/projects/rfm/ 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.
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.
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.
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.