Bill Michael wrote:

>>One thing I think would be really useful right now is a set of FB Include
>>files that would communicate with FileMaker via AppleEvents.
>>
>>I've started looking into doing this, but I need to learn some more about
>>AppleEvents.  Staz's filter will help.
>
>FileMaker connectivity would be _very_ good. It's cheap, commonly used, 
>and very AE-friendly. Staz's filter is great, but be warned; you'll be 
>making some _real_ serious changes to it to get it "talking" to 
>FileMaker. FileMaker has grown enough now to be a "serious" database even 
>in my book - and I've worked with terabyte databases hosting 2000+ users. 
>Until the last couple of years, 4D was the only "real" Mac option I saw. 
>Now, the only thing that bothers me about FileMaker is the way Apple has 
>treated so _many_ of their great products. EMailer, Newton, OpenDoc, 
>CyberDog, Copland, etc., etc...

IMO, tools to allow _easy_ communication between a low-level development 
environment and any database product are essential for the long-term 
survival of those environments (including FB). The only sanctioned method 
in medium to large companies to communicate with data storage 
environments is via ODBC/SQL.

I just got back from the FileMaker Developer Conference and I've got 
several comments regarding the above.

1) FileMaker v4.1, due out in a couple of weeks, supports SQL queries 
(SELECT) against remote databases using ODBC. In other words, use 
FileMaker as a front-end to Oracle, Sybase, SQL Server, etc. There is 
also a 3rd-party FileMaker plug-in that does full SQL support (CREATE, 
INSERT, etc.). There's enough beef there to make the corporate IT types 
nervous about users having the ability to easily query the data 
warehouse...

2) FileMaker is highly scriptable using AppleScript/Apple Events. It 
works well and with OS 8.5's improved network speed and native 
AppleScript, the performance boost could be as much as 5 times faster 
than it is now. FileMaker's AppleScript/Apple Event support works with 
everything from the basic data manipulation commands to the Web Companion 
to the ODBC capabilities, making FileMaker a powerful ally to any app 
capable of sending/receiving Apple Events.

3) Last January, FileMaker, Inc. was split out of Claris. It is operating 
as an _independent_ but wholly owned subsidiary of Apple, however Apple 
has no direct influence on product direction or marketing. They are 
focused on a single product line: FileMaker Pro products (including Home 
Page). After viewing the marketing and product development plans for the 
FileMaker Pro product line and the current and projected sales revenues, 
I can assure you that this is not another case of a great 
technology/product that Apple will abandon. In fact, FileMaker is the #1 
selling database on the Mac and  #2 on the dark side (actually it is the 
#1 _standalone_ database product on the dark side--you have to look at 
standalone numbers because Access is bundled with MS Office, thus has the 
largest distribution on the dark side, even though it is unused with most 
copies of Office installed). Note also that I said product _line_ not 
simply product. FileMaker is already multiple products, including 
FileMaker Pro, FileMaker Pro Server, FileMaker Pro Developer Edition, 
FileMaker Pro Runtime, Home Page. You will see significant expansions of 
this line in the future.

4) FileMaker (indeed most modern database tools including Visual FoxPro 
for Mac, 4D, Omnis, Helix, etc.) has enough built-in 
scripting/programming capability so that it is no longer necessary to 
build a FB, C, C++, Pascal (choose one) front end to the data. It's a sad 
fact to me, but a reality, that I've had no clients for coming up on 3 
years who would pay for custom development work using any tool other than 
a database product and its built-in scripting/programming tools. I've 
made a darn good living selling systems based completely on FileMaker, 
4D, VFP, and SuperCard. The only "real" programming I've had to do was an 
occasional XCMD/XFCN or FileMaker plug-in. I believe most small 
developers are finding themselves in the same situation. Unless you're 
writing development tools, utilities or games, you can create awesome and 
powerful systems quickly and easily without resorting to low-level 
programming tools (and the frustrations and headaches derived from their 
use).

Jeff