To FileMaker, or not to FileMaker...

[Coby Beck]

Hello Group,

I am currently involved in a situation that has evolved over several years
and would like a little insider information on FileMaker's suitability to
our task.

Situation: company has existing FileMaker database. It handles basic needs
but really needs a redesign. Two years ago company decided to switch to a
web browser interface (served by Zope) and a PostgreSQL dB running on Linux.
Time passes, shoddy software company never delivers, money is spent, time is
wasted. I came on the scene 4 months ago to "rescue" the situation. Now
company is reconsidering leaving FileMaker at all as they have heard of many
additional capabilities that the old versions did not have. This would
change my job but not eliminate it, though my personal preference is to not
change directions now.

Required capabilities: I do not know much about FileMaker and its new or
old capabilities, but here are the original reasons for desiring a change:
access from the web, better security in terms of controling who can access
what information, scalability for current and predicted company growth. We
have very near term plans for 4 different office locations around the
country and the system is for construction Project Management and Financial
Planning. I forsee 10-20 concurrent users and tables with hundreds of
thousands of records. I forsee the need to use it and develope it
simultaneously.

What would it take for FileMaker to meet this challenge?

Thank you for your time in reading and responding!

--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")

[Coby Beck]

"Tim Booth" <tbooth@usyd.edu.au> wrote in message
news:3F08BF19.319AE594@usyd.edu.au...

>
>
> Coby Beck wrote:

> >
> > Hello Group,
> >
> > I am currently involved in a situation that has evolved over several

years

> > and would like a little insider information on FileMaker's suitability

to

> > our task.
> >
> > Situation: company has existing FileMaker database.

>
> Version??

a mix of 3 and 4

> > It handles basic needs
> > but really needs a redesign. Two years ago company decided to switch to

a

> > web browser interface (served by Zope) and a PostgreSQL dB running on

Linux.

>
> Interesting choices - Zope can be really good, or really bad...
>

> > Time passes, shoddy software company never delivers, money is spent,

time is

> > wasted. I came on the scene 4 months ago to "rescue" the situation.

Now

> > company is reconsidering leaving FileMaker at all as they have heard of

many

> > additional capabilities that the old versions did not have.

>
> Sorry, should this sentence read they want ot keep FM or they want out
> of FM??

They are rethinking the decision from two years ago to leave FileMaker. So
they wanted out, have gone far down that road and now think they may want to
stay.

> > This would
> > change my job but not eliminate it, though my personal preference is to

not

> > change directions now.
> >
> > Required capabilities: I do not know much about FileMaker and its new

or

> > old capabilities, but here are the original reasons for desiring a

change:

> > access from the web,

>
> Done natively from FM these days.

> > better security in terms of controling who can access
> > what information, scalability for current and predicted company growth.

We

> > have very near term plans for 4 different office locations around the
> > country

>
> Which country? You are using both an Australian and Canadian email
> in this - judging from the timezone, I'd say east coast of Australia
> somewhere...

Excellent deductions, Holmes ;) Northern Tasmania to be precise. (Though I
am Canadian, I don't know where anything about that would have slipped in to
the equation. Australian ISP, laptop and email account...are you psychic?)

> > and the system is for construction Project Management and Financial
> > Planning. I forsee 10-20 concurrent users and tables with hundreds of
> > thousands of records. I forsee the need to use it and develope it
> > simultaneously.
> >
> > What would it take for FileMaker to meet this challenge?

>
> A really decent back-end network architecture plan. The only bit I
> see problems with is the multiple remote locations. A lot of reading
> and basic data entry can be built onto the web capabilities, which
> is quick over slow connections, but design and real data input is
> best done through the FM interface - which is very bandwidth
> intensive and really can't be done properly over dialup, for instance.

Are there any concerns about the size of the data? I recall from working
with MSAccess a while ago that things get very bogged down when the record
counts get high. Also a problem was needing custom software installed on
all the client machines. Would all the users have to have concurrent
versions of the FileMaker's client side?

Also, how controllable is access to the data on a per user basis?

> VPNs and a decent connection between your offices will eb required for
> that.
>
> After that...
>
> Well, I'd probably either get a consultant, or read up real close on
> the best practices for networking FM databases.

Ever been to Tasmania? ;)

--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")

[Lynn allen]

Coby Beck <cbeck@mercury.bc.ca> wrote:

>
> a mix of 3 and 4

Version 6, while recognizeably the same product, has so many new
features (including some very developer-friendly ones delivered in FM
5.5) you'll be amazed. Visit the Filemaker website, they have a spot
where you input your current version & you get a rundown on just what
has changed from then until the current version.

For instance, there is now a version of FM Server which runs on Red Hat
Linux. :) But wait, there's MORE!....

>
>

> > > and the system is for construction Project Management and Financial
> > > Planning. I forsee 10-20 concurrent users and tables with hundreds of
> > > thousands of records. I forsee the need to use it and develope it
> > > simultaneously.

Well, I hope you mean that you'll be developing offline and upgrading in
phases or during downtime. Making major changes to live systems is
problematic, as network connection loss during certain vital operations
can mean utter corruption of the files to the point of unuseability.
Normally development means a single path from pristine developer files
up to the served, live files. Every upgrade means importing the data
into the new set of files, as in Filemaker the code and interface are
intermingled with the data. Working on live files and not having
virgin files which have never been served is not best practice for
maintaining robust file health.

However, if we're talking about things like "move this field on this
report here, RIGHT NOW! because the CO wants this report in five
minutes" that works really well in FM.

> > >
> > > What would it take for FileMaker to meet this challenge?

> >
> > A really decent back-end network architecture plan. The only bit I
> > see problems with is the multiple remote locations. A lot of reading
> > and basic data entry can be built onto the web capabilities, which
> > is quick over slow connections, but design and real data input is
> > best done through the FM interface - which is very bandwidth
> > intensive and really can't be done properly over dialup, for instance.

There are also options for Citrix and Terminal Services which allow much
faster remote connection. Lower cost options include Timbuktu or
PCAnywere/VPN connection.

>
> Are there any concerns about the size of the data? I recall from working
> with MSAccess a while ago that things get very bogged down when the record
> counts get high. Also a problem was needing custom software installed on
> all the client machines. Would all the users have to have concurrent
> versions of the FileMaker's client side?

Depending on complexity of data and the architecture of the solution,
you'll be ok at hundreds of thousands of records. For pure reference,
some FM solutions have gotten up into several millions of records, but
practically speaking, pure Filemaker is less than optimum for those
kinds of deployments. Importing millions of records during upgrades is a
real mood (and weekend) killer. We wish for separation of data and
interface/code but we don't have it yet.

Also you might consider using FM as a front end for your SQL solution.
There are all sorts of nifty connection tools, including plugins.
Reports from experts in the field show that FM as a front end can be
MUCH faster than pure FM, and gives you the tools that make building FM
interfaces such a joy, while allowing the benefits of high record counts
and robust data handling.

LAN connections to FM do require an install on each client machine. Web
connections require a browser.

>
> Also, how controllable is access to the data on a per user basis?
>

Using a VPN is going to help a lot with security from the outside.
Building a login/permissions system which extends and augments the
native FM password/access capabilities will help keep users from
shooting themselves in the foot. Neither will keep out a really
determined hacker. Filemaker is NOT the place to store military secrets
or tremendously sensitive or valuable personal or corporate information.

I also concur that consulting a professional might not be a bad idea as
you explore your options. I don't know anyone right in Tasmania, but I
do know several in Oz & NZ, and they might know of someone more local to
you. Let me know if you need references.


--
Lynn Allen Allen & Allen Semiotics
FSA Associate Filemaker Consulting & Training
[email]lynn@semiotics.com[/email] [url]http://www.semiotics.com[/url]

[Coby Beck]

"Tim Booth" <tbooth@usyd.edu.au> wrote in message
news:3F08DF8C.512178C1@usyd.edu.au...

> > > Which country? You are using both an Australian and Canadian email
> > > in this - judging from the timezone, I'd say east coast of Australia
> > > somewhere...

> >
> > Excellent deductions, Holmes ;) Northern Tasmania to be precise.

(Though I

> > am Canadian, I don't know where anything about that would have slipped

in to

> > the equation. Australian ISP, laptop and email account...are you

psychic?)

>
> No, your newsreader has a .ca address set as the return address...

Ah. I forgot about that...an old work email left to trap spam.

> > Are there any concerns about the size of the data? I recall from

working

> > with MSAccess a while ago that things get very bogged down when the

record

> > counts get high.

>
> A well-designed solution shouldn't suffer from high record counts...
> it all depends on how many calculations and scripts are being used

There will be some hairy calculations. They are currently done at the UI
layer for the most part. I would probably revisit that.

> > Also a problem was needing custom software installed on
> > all the client machines. Would all the users have to have concurrent
> > versions of the FileMaker's client side?

>
> Every seat would require a FileMaker licence and install, unless
> they are only using the web interactions - which just requires a
> browser.

I imagine it will end up a mix of both. Can you simply
point-click-publish-to-web the regular forms and dialogues? That sounds
like a tall order, maybe at least some reuse of interfaces between native
FileMaker and web-browser is possible?

> > Also, how controllable is access to the data on a per user basis?

>
> Fair to good, depending on how well the developer understands
> the idiosyncracies of FM's password system... it can be a little
> arcane in my opinion.

As I don't think the goal is necessarily to be hacker-proof, perhaps filters
in forms and hidden tables/fields will suffice. I assume forms can be
locked at direct views of the database can be hidden?

Thanks for your responses.

--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")

[Coby Beck]

"Lynn allen" <lynn@NOT-semiotics.com> wrote in message
news:1fxoxr2.1x0dbl81j5jnvxN@[192.168.1.101]...

> Coby Beck <cbeck@mercury.bc.ca> wrote:

> >
> > a mix of 3 and 4

>
> Version 6, while recognizeably the same product, has so many new
> features (including some very developer-friendly ones delivered in FM
> 5.5) you'll be amazed. Visit the Filemaker website, they have a spot
> where you input your current version & you get a rundown on just what
> has changed from then until the current version.
>
> For instance, there is now a version of FM Server which runs on Red Hat
> Linux. :) But wait, there's MORE!....

> >
> >

> > > > and the system is for construction Project Management and Financial
> > > > Planning. I forsee 10-20 concurrent users and tables with hundreds

of

> > > > thousands of records. I forsee the need to use it and develope it
> > > > simultaneously.

>
> Well, I hope you mean that you'll be developing offline and upgrading in
> phases or during downtime. Making major changes to live systems is
> problematic, as network connection loss during certain vital operations
> can mean utter corruption of the files to the point of unuseability.
> Normally development means a single path from pristine developer files
> up to the served, live files. Every upgrade means importing the data
> into the new set of files, as in Filemaker the code and interface are
> intermingled with the data. Working on live files and not having
> virgin files which have never been served is not best practice for
> maintaining robust file health.
>
> However, if we're talking about things like "move this field on this
> report here, RIGHT NOW! because the CO wants this report in five
> minutes" that works really well in FM.

> > > >
> > > > What would it take for FileMaker to meet this challenge?

>

> > >
> > > A really decent back-end network architecture plan. The only bit I
> > > see problems with is the multiple remote locations. A lot of reading
> > > and basic data entry can be built onto the web capabilities, which
> > > is quick over slow connections, but design and real data input is
> > > best done through the FM interface - which is very bandwidth
> > > intensive and really can't be done properly over dialup, for instance.

>
> There are also options for Citrix and Terminal Services which allow much
> faster remote connection. Lower cost options include Timbuktu or
> PCAnywere/VPN connection.

> >
> > Are there any concerns about the size of the data? I recall from

working

> > with MSAccess a while ago that things get very bogged down when the

record

> > counts get high. Also a problem was needing custom software installed

on

> > all the client machines. Would all the users have to have concurrent
> > versions of the FileMaker's client side?

>
> Depending on complexity of data and the architecture of the solution,
> you'll be ok at hundreds of thousands of records. For pure reference,
> some FM solutions have gotten up into several millions of records, but
> practically speaking, pure Filemaker is less than optimum for those
> kinds of deployments. Importing millions of records during upgrades is a
> real mood (and weekend) killer. We wish for separation of data and
> interface/code but we don't have it yet.

I must confess this has been my biggest concern.

> Also you might consider using FM as a front end for your SQL solution.
> There are all sorts of nifty connection tools, including plugins.
> Reports from experts in the field show that FM as a front end can be
> MUCH faster than pure FM, and gives you the tools that make building FM
> interfaces such a joy, while allowing the benefits of high record counts
> and robust data handling.

This sounds great! It seems like the best of both worlds and means
salvaging 90% of the work already done on the database schema, rules and
triggers. Oh. What about linking forms to SQL views as opposed to an
actual table? In the current design, all user input goes through SQL views
and gets munged by "ON INSERT into VIEW vFoo DO" code.

> LAN connections to FM do require an install on each client machine. Web
> connections require a browser.

> >
> > Also, how controllable is access to the data on a per user basis?
> >

>
> Using a VPN is going to help a lot with security from the outside.
> Building a login/permissions system which extends and augments the
> native FM password/access capabilities will help keep users from
> shooting themselves in the foot. Neither will keep out a really
> determined hacker. Filemaker is NOT the place to store military secrets
> or tremendously sensitive or valuable personal or corporate information.
>
> I also concur that consulting a professional might not be a bad idea as
> you explore your options. I don't know anyone right in Tasmania, but I
> do know several in Oz & NZ, and they might know of someone more local to
> you. Let me know if you need references.

Thanks, I'll keep that in mind. I would expect it to be a matter of
configuring ODBC connections etc and thus hopefully not so difficult. Have
you any experience with MSAccess? I did quite a bit of developing in that
once apon a time, so my expectations are along those lines...drag and drop
widgets, point and click to select field sources..that kind of thing.

Thanks for you

> --
> Lynn Allen Allen & Allen Semiotics
> FSA Associate Filemaker Consulting & Training
> [email]lynn@semiotics.com[/email] [url]http://www.semiotics.com[/url]

[Coby Beck]

"Coby Beck" <cbeck@mercury.bc.ca> wrote in message
news:bedsb5$1pdu$1@otis.netspace.net.au...

> Thanks for you

r continued help!

(don't know what I hit, but the message found its way to usenet without
waiting fo me to finish!)

--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")

[Frank]

Coby,
Sorry for "jumping in" here....

Although my requirement is not immediate, I have a need to allow
access to a FM database via dial-up or the web also. I am looking at
using Windows Terminal Services or Linux Terminal Services to provide
this access and control.

As for the individual licenses, I was looking at acquiring the FM
Developer 6 version to allow me to develop Runtime versions of my
applications.

These are all under evaluation for my situation, but they may be
avenues for you to explore also.

Just some thoughts...

[Tim Booth]

Frank wrote:

>
> Coby,
> Sorry for "jumping in" here....
>
> Although my requirement is not immediate, I have a need to allow
> access to a FM database via dial-up or the web also. I am looking at
> using Windows Terminal Services or Linux Terminal Services to provide
> this access and control.
>
> As for the individual licenses, I was looking at acquiring the FM
> Developer 6 version to allow me to develop Runtime versions of my
> applications.

Big note: Runtime versions are not networkable. They are *only*
able to be used standalone... if you have more than one user
using a solution, it becomes very difficult to keep data in synch

Webko

[Coby Beck]

"Tim Booth" <tbooth@usyd.edu.au> wrote in message
news:3F0CA257.423874B2@usyd.edu.au...

> Frank wrote:

> >
> > As for the individual licenses, I was looking at acquiring the FM
> > Developer 6 version to allow me to develop Runtime versions of my
> > applications.

>
> Big note: Runtime versions are not networkable. They are *only*
> able to be used standalone... if you have more than one user
> using a solution, it becomes very difficult to keep data in synch

I read this and didn't quite understand it. But now, discussing product
purchase with the FM people I take it to mean that I cannot create a
standalone executable that will be able to connect to a server, it must be
its own database as well as interface. Ok, so we spend a few more dollars,
install the developer version on every user's machine and away we go, right?
Any other 'gotcha's?

--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")

[Tim Booth]

Coby Beck wrote:

>
> "Tim Booth" <tbooth@usyd.edu.au> wrote in message
> news:3F0CA257.423874B2@usyd.edu.au...

> > Frank wrote:

> > >
> > > As for the individual licenses, I was looking at acquiring the FM
> > > Developer 6 version to allow me to develop Runtime versions of my
> > > applications.

> >
> > Big note: Runtime versions are not networkable. They are *only*
> > able to be used standalone... if you have more than one user
> > using a solution, it becomes very difficult to keep data in synch

>
> I read this and didn't quite understand it. But now, discussing product
> purchase with the FM people I take it to mean that I cannot create a
> standalone executable that will be able to connect to a server, it must be
> its own database as well as interface. Ok, so we spend a few more dollars,
> install the developer version on every user's machine and away we go, right?

Well, preferably no actually :-)

The product lineup:
FM Server - holds and serves FileMaker database files. No actual
FM functionality
FM Pro - Normal client version. Install on machines, they connect
to server, people data enter, do reports, whatever
FM Unlimited - Web server version. Identical to Pro, but unlimited
access via the web
FM Developer - Same as Pro with some additional cool tools to create
standalone runtimes (means client machine doesn't have to have
FileMaker, but the files can't be networked/multi-user) and
some other stuff to quickly rename files, perform debugging.

So, FM Server as the backend, FM Pro for normal users to access
and manipulate databases, the other 2 if you want to be fancy...
Much cheaper than buying Developer for everyone too :-)

Webko

[Ryan Costello]

> Also you might consider using FM as a front end for your SQL solution.
> There are all sorts of nifty connection tools, including plugins.
> Reports from experts in the field show that FM as a front end can be
> MUCH faster than pure FM, and gives you the tools that make building FM
> interfaces such a joy, while allowing the benefits of high record counts
> and robust data handling.
>

I will throw my two bits into this thread and just say i agree 100% with
this statement. Filemaker is a great tool but when you are getting into the
hundreds of thousands of reconds range it starts to become unusable as a
data source. It can handle this many records by itself, but it becomes more
of a pain than its worth at this point. Filemaker as a front end to a
powerful SQL database though is the best of both worlds. You get the user
friendly intuitive front end with a fast SQL based back end.

Ryan

[Jay Gonzales]

> Required capabilities: <snip>

> access from the web, better security in terms of controling who can access
> what information, scalability for current and predicted company growth. We
> have very near term plans for 4 different office locations around the
> country and the system is for construction Project Management and Financial
> Planning.
> I forsee 10-20 concurrent users and tables with hundreds of
> thousands of records. I forsee the need to use it and develope it
> simultaneously.

Take a look at SyncDeK: <http://www.syncdek.com/>
This is data replication and synchronization technology for
FileMaker, and can be installed with almost any existing FileMaker
database.

SyncDeK would enable you to run local copies of your database on a
Server at each location, or on laptops for individual users who can
work offline. SyncDeK will replicate changes made in each database,
and synchronize the data between everyone.

Jay Gonzales
SyncDeK(tm) - A.E. Wood & Erickson
[url]http://www.syncdek.com/[/url]