| [reply] |
The 30 day trial version should buy you some time.
Filemaker does actually have an ODBC capability, but I believe it has to be running as a daemon unlike others of it's ilk (read: M$ Access). If you're in *nix you could run it under Win4lin or VMWare and use an ODBC bridge to connect to it for the time being.
That said, virtualsue is right on the mark; getting their data into a more managable format is a very good idea. Even if you have to do some form of XML replication and parsing between their version and (I'm assuming) the web/intranet version you're developing, it's often worth the price for a well normalised database and good DBMS engine (though not always).
The DBI module is quickly becoming a favourite of mine. I was amazed at the level they took DBD::CSV too, very nice for quick work. If it's mainly content pull MySQL is a nice light-weight uberfast engine. Up a few steps is PostgreSQL if you need things like row level locking*, foreign key relations/contraints, sub selects, transactions**, stored procedures, et al. I'm assuming the $$$ DBMSs like Oracle are out of the question.
I had to revise this a few times, I'm a DBA and such products as "Filemaker" incite less than complimentary remarks from me normally. ;)
* Coming in MySQL 4
** MySQL's isn't nearly as robust, though it is there for a specific table type
| [reply] |
Filemaker Pro will export to a tab or comma delimited format, html table files, as well as:
SYLK
.DBF
.DIF
.wk1 (lotus 123)
.bas (BASIC files)
.mer (merge files)
It can also be set up to run as a web server. If your client is off-site you could perhaps be gathering info updates without having them send you exports, by issuing http requests to their system and extracting info from the replies.
If you want to go uberschnappen then you can learn CDML & create custom templates designed to be hit by your code that would be more efficient than using their GUI tools to build pages.
BUT, with regards to simply parsing the file format, no, it doesn't exist, yet. You've now given me a project, since I'm very familiar with FMPro, I guess I'm elected. Stay Tuned...
Wait! This isn't a Parachute, this is a Backpack!
| [reply] |
OK after taking a long look at the file format, I see that it's basically a binary format with ASCII values embedded.
There's a lot of information in there that you also don't care about, for example, layout names, GUI info, creation date info fot he DB file itself, printer drivers, & what looks like serial number hashes as author stamps. (Not a listed feature mind you.)
The binary info doesn't line up to a consistent ASCII representation for a delimiter string, so though you can grep through & find the info, that won't help you parse it worth a damn.
What I DID think of however, was that an access mechanism could be written somewhat trivially using an AppleScript/PERL hybrid. Naturally this would only work under Mac OS, so odds are that doesn't help. But it does give me an easier way to solve this problem. Unfortunately I have no macs @ work. ); So It'll have to wait until I get home tonight.
Wait! This isn't a Parachute, this is a Backpack!
| [reply] |
Upon looking in Super Search for Filemaker I found a reference to this:
Mac::Glue which also looks very promising. But again, only if you're on the Macintosh platform, since it relies heavily on Apple Events, which is a Mac OS feature.
Wait! This isn't a Parachute, this is a Backpack!
| [reply] |