There were some bug fixes (PDF), but no real changes. Conditional
formatting should have been a 8.5vxxx fix, not a whole upgrade. Yes it
reads & writes fp7 files. But like the TABS, (handy but not fp7
compatible) so taking advantage of the formatting changes is not wise.

SQL improvements, nesting scripts by categories is cute.

Otherwise, what are the reasons to upgrade?

--
-------------------------------------------------
Captain Guy
s/v Island Time (Beneteau 352#277)
AICW 845.5
386-689-5088

On Jul 11, 7:23 am, "Guy" <sai... (AT) guym (DOT) com> wrote:
The two features I think would be most useful to the 'common
developer', Set Field and script triggering via the calc engine, are
missing.

I think Filemaker's strategy is to expand certain markets, namely mid-
to large-sized companies that currently use SQL-based systems by
presenting FM9 as an easy-to-develop front-end to those systems. If
that's not you or your client base, I don't see a whole lot reason to
upgrade at this time.

I'm glad, that they came up with a new version. I'm currently running FMA8
and planning to upgrade my hardware (mac) next fall to an Intel-machine. By
getting a universal-upgrade, I'll get some nifty features as well like
web-views and conditional formatting, which I was badly missing in version
8.

My suggestion for Filemaker Team - I know, you're reading this newsgroup ;-)

You should include some more extra in Advanced-version. For example that
graphics-pack and those templates, that you offered as sales-gimmicks some
time ago.

-antti-


On 11.7.2007 17:40, in article
1184164816.006966.65360 (AT) 22g2000...oglegroups.com, "Grip"
<grip (AT) cybermesa (DOT) com> wrote:

Guy wrote:
The SQL integration is a HUGE reason to upgrade, but admittedly only for
companies who need to tie in. Or for companies who are skeptical about
keeping their data in the proprietary FileMaker files, the data can now
be kept in a SQL backend while seamlessly using FM9 as a front end.

Beyond that, there have been a lot of nice changes with the script
debugger and with ScriptMaker. Debugger now shows all stored variables
and active global field settings by default. ScriptMaker now allows you
to have multiple script windows open at once (so, for example, you can
copy script steps in one window and paste them in another, back and
forth if you want). You can keep scripts open while they run, edit
them, run them again, all without fussing with closing ScriptMaker,
reopening, finding your script, etc. Two people can edit different
scripts in the same file simultaneously. You now have the ability to
filter scripts in the ScriptMaker window to more easily find the script
you want to work on. You can now categorize scripts to, again, more
easily view just the set of scripts you want to work with at that time
and to declutter the ScriptMaker window.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg
FM Professional Solutions, Inc. Los Angeles

FileMaker 8 Certified Developer
Member, FileMaker Business Alliance

"Antti Ussa" <anttiussa (AT) hotmail (DOT) com> wrote

I'd like to see better run time support for developing applications.

Window control, real modal dialog boxes, multi-user support, installer
(instead of using WISE), etc.

While MS aceess is no fun to develop, you do get run-times that look like
apps.

Guy

On Wed, 11 Jul 2007 14:40:16 -0000, Grip <grip (AT) cybermesa (DOT) com> wrote:

You nailed it. For me version 9 could be a very big deal.

For example, I have one client who has two crucial SQL systems that he
can't administrate on his own. This person runs a home-based business
and everyone there is kind of computer intimidated. Some time ago I
built him a solution in FMP 8.0 which he swears by. When he needs
data uploaded to SQL he usually calls me. But now his business has
grown to the point where he needs to have this capability in-house. He
hates computers et cetera but he LOVES FileMaker (well, he loves the
solution I built for him) and if I can build him a SQL front end in
FMP he will be in heaven. But it needs to exchange data readily (FMP
<-> SQL), not just browse SQL records on an FMP layout.

I've downloaded but not installed version 9 -- I'll post my
impressions when I get it running.

--
FW

On Jul 11, 8:28 am, Howard Schlossberg
<how... (AT) nospam (DOT) fmprosolutions.com> wrote:
So... its a worthwhile upgrade for -developers- (like us), and for
shops that do sql integration. But it almost seems like a lot of shops
(FM Server + 10-50 clients and 1 or 2 developers... could stay on
8/8.5, and just have the dev machines upped to 9. Or am I missing
something... like a new fileformat??

-Dave

d-42 wrote:

Well, there's conditional layout formatting, which is worth a look and
will only display on FM9 clients. There's also a new feature that
allows fields to expand as you drag the window wider. There's also more
control over tab layout objects.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg
FM Professional Solutions, Inc. Los Angeles

FileMaker 8 Certified Developer
Member, FileMaker Business Alliance

Guy <sailor (AT) guym (DOT) com> wrote:

For us, this is are great reason:

Perform searches and calculations faster
The server automatically performs certain searches and calculations on
the server instead of the local client. This decreases the time required
to provide a result, so you can work faster and minimize disruption to
your users.
Schedule scripts to run automatically

Now, many scripts can be scheduled to run on the server.* Scripts that
clean data, such as scripts that remove duplicate records or format
address and phone data, can be scheduled to run on the server.
Server-side scripts, as well as backups, can be scheduled to run at
off-peak hours.

And best of all, to take advantage of this futures, we must not upgrade
clients.

The biggest deal about FileMaker 9:

If you can live with some of the limitations, you could obviate the need for
FileMaker Server by using MySQL as your central repository and simply
deploying FileMaker as a "front end."

The biggest obstacle here would be switching to a tool like HeidiSQL for
adding new fields, because FileMaker 9 can't do jack with the remote schema.
But once the fields are defined, you can switch back to FileMaker and set up
calculations, layouts, reports, you name it. Unstored calculations can even
"live" side-by-side in the remote table, as far as you the developer is
concerned.

There also seem to be serious performance issues with doing finds across
tables -- i.e.: you search for invoices within a date range AND a certain
part number among the line items -- where FileMaker is doing multiple SQL
queries that are horribly slow and inefficient. But it seems that could be
mitigated through careful system design and keeping everything on a
high-performance network and server.

The advantages:

- Using (or continuing to use) the tools of your choice for web presentation
of the SQL data (formerly required the $2500 FileMaker Server Advanced)
- Exceeding the 250-FileMaker user limit on hosted databases
- Exceeding the 100-Web user limit on hosted databases
- Each client has the ability to serve up the data via IWP (5 web clients
each)
- Ability to use FileMaker's layout, scripting, validation and calculation
tools for process flow, reports, data entry and presentation (which most
people consider to be the "hard" part about working with SQL)

Of course the big fly in this ointment is that to do this magic, FileMaker
needs an ODBC driver for MySQL. On Windows, there's a reasonably good free
driver from MySQL but the free one for Intel Macs at this time it very
difficult for a lay person to install (you'll more likely have to pony up
the cash for Actual's driver at $30/seat). Even then, the huge drawback is
having to install and configure the ODBC driver on every client PC that will
use FileMaker. If FileMaker really wanted to make a splash, they would have
had native support for MySQL like many other products do.