Thanks for answering to the previoust post of mine.

I've understood , even reading articles on the Internet, that basically the
products have different approaches to the problem (managing a DB).

Looks like Access is uglier and not so User-Interface-Smart (I confirm, just
ended developing a small project, but must admit it looks much better under
Windows XP) requires more coding (IMHO this could be a strength in terms of
flexibility, and VBA is easy), not cross platform, but more scalable and
powerful when coupled with MS SQL Server 2000, even if not so good at
dealing with record locking strategies (must go "manually coded" to
implement a near perfect strategy).

Having said that, I'm not scared about getting me or my staff into a new
product, but what I want  now is to choose the best product for my client
assuming that:

- my client has  5 to 10 "forms" developed with FM6, scattered on a few
un-networked pcs/Apples, with say 5/8 tables not optimized, not normalized
etc.

- the client wants to expand the existing (even if probably will need to
redesign entirely the database structure and relationships) go client/server
in a mission critical environment (client/server, multiuser, 24hrs a day 365
days a year, from tens to hundreds thousands records) so the application
must be: reliable, fast ,scalable, and rely on a robust back-end.

- the client dislikes Access and loves FM, you know! :)

Probably the best would be developing a custom application in C++ or VB + a
strong SQL server in the back end, BUT as my client would like to stick with
FM, keep budget as low as possible and as I've just completed a small
project with Access 2003 and SQL server 2000 (knowing exactly weaknesses and
strenghts of the couple), here I am, making up my mind!

Any comment appreciated!

Atlas <atlaspeak@my-deja.com> wrote:

> Having said that, I'm not scared about getting me or my staff into a new
> product, but what I want  now is to choose the best product for my client
> assuming that:
> 
> - my client has  5 to 10 "forms" developed with FM6, scattered on a few
> un-networked pcs/Apples, with say 5/8 tables not optimized, not normalized
> etc.
> 
> - the client wants to expand the existing (even if probably will need to
> redesign entirely the database structure and relationships) go client/server
> in a mission critical environment (client/server, multiuser, 24hrs a day 365
> days a year, from tens to hundreds thousands records) so the application
> must be: reliable, fast ,scalable, and rely on a robust back-end.
> 
> - the client dislikes Access and loves FM, you know! :)

This right here is the most important sentence you wrote. 
> 
> Probably the best would be developing a custom application in C++ or VB + a
> strong SQL server in the back end, BUT as my client would like to stick with
> FM, keep budget as low as possible and as I've just completed a small
> project with Access 2003 and SQL server 2000 (knowing exactly weaknesses and
> strenghts of the couple), here I am, making up my mind!

The important factor is "can the tool the customer likes the best
(translation: is most willing to pay for, invest development time in,
and adapt to once developed) do the job?"

If the capacity of FM is adequate, which it seems it is, with an upper
limit of hundreds of thousands of records, then go with FM. FM is fully
capable of a robust deployment to support 24/365 reliability, will
support multiple users up to 250 concurrently, gives you the EASIEST
options overall when it comes to web deployment, and will let you
prototype and finalize at a lower cost than any of your other options,
given an experienced developer. 

A consultant has the obligation to counsel against using a particular
tool if the tool isn't suitable for the job. Otherwise, counseling the
client not to use a tool they like because the CONSULTANT doesn't know
it means the client has the wrong consultant, not the wrong tool. ;)

It's hard enough to introduce a new software into a corporate
environment and get over that hump of acceptance and use when the people
already like and use a particular tool. Trying to force an undesired
tool into the corporate environment is too much work. At least in my
opinion. I wouldn't go into a project where the client REALLY liked
Access/SQL and hated FM and try to sell them on the idea that no, they
really need FM instead.

You've got the sale practically made if you select FM. The issue is in
doubt if you select something else. How badly do you need the work? How
much are you willing to invest in learning a new tool?   Always good
questions for any consultant. :)

Lynn Allen
---
www.semiotics.com

Lynn, thanks for answering

> If the capacity of FM is adequate, which it seems it is, with an upper
> limit of hundreds of thousands of records, then go with FM. FM is fully
> capable of a robust deployment to support 24/365 reliability, will
> support multiple users up to 250 concurrently,

(cut)

Do you know how it beheaves with a SQL Server in the back end? You know, to
cut down development could make sense to use a SQL Server  (like MS) that
soars (and it's a well known product in my team) or any known drawback
(speed, crashes, glitches....).

Thanks again for answering

Atlas wrote:

> Lynn, thanks for answering
> 
> 
>>If the capacity of FM is adequate, which it seems it is, with an upper
>>limit of hundreds of thousands of records, then go with FM. FM is fully
>>capable of a robust deployment to support 24/365 reliability, will
>>support multiple users up to 250 concurrently,
> 
> 
> (cut)
> 
> Do you know how it beheaves with a SQL Server in the back end? You know, to
> cut down development could make sense to use a SQL Server  (like MS) that
> soars (and it's a well known product in my team) or any known drawback
> (speed, crashes, glitches....).

If you want to cut down development, why use SQL Server at all? FM 
Server would be much quicker, easier, and cheaper in this case, and 
would work much better than using an FM client to act as an SQL client 
for SQL server.

With FM Server, there is no extra development required. Just take your 
multi-user FM database and put it on the server.

Atlas wrote:
> Lynn, thanks for answering
> 
> 
>>If the capacity of FM is adequate, which it seems it is, with an upper
>>limit of hundreds of thousands of records, then go with FM. FM is fully
>>capable of a robust deployment to support 24/365 reliability, will
>>support multiple users up to 250 concurrently,
> 
> 
> (cut)
> 
> Do you know how it beheaves with a SQL Server in the back end? 

It can pull data against SQL server in the backend if it has too, but 
that is the most absurd thing you could do when setting up a new FM 
deployment, given that it was designed from the ground up to work with 
FM server, and -that- is where its easiest to use, fastest to run, 
fastest to develop, and most powerful.

SQL is like French and FM is like Spanish. FM took some French courses, 
so it can talk to SQL, and it can get along in France ok when it needs 
to make a business trip. But its a 2nd language after all -- and if you 
want FM to really fly you'll let it work in its native tongue Spanish.

>You know, to
> cut down development could make sense to use a SQL Server 

Not particularly, imo. I'd say that would increase development costs 
(and software costs), and slow down the application.

> (like MS) that
> soars (and it's a well known product in my team) or any known drawback
> (speed, crashes, glitches....).


> Thanks again for answering

Like Lynn said, the customer likes FM, it sounds like FM will do the job 
admirably, the last thing you want to do is deliberately throw a 
sql-server-monkey-wrench into the mix for no reason at all other than 
the fact that you are familiar with it.

Atlas <atlaspeak@my-deja.com> wrote:

> Do you know how it beheaves with a SQL Server in the back end? You know, to
> cut down development could make sense to use a SQL Server  (like MS) that
> soars (and it's a well known product in my team) or any known drawback
> (speed, crashes, glitches....).

I'd go with a straight FM Server/FM Pro client deployment. SQL Server is
not the right data depository for FM, although FM can act as a front end
to SQL with a bunch of (extra) coding.  It works quite well if you have
an existing SQL setup and want to pull data through ODBC, but frankly,
SQL Server is an extra expense and an extra headache in a project like
you're talking about. Sort of like adding a travel trailer onto your
Lambourghini. 

Right out of the box, FM Server will handle all those pesky little items
like robust record locking, calc offloading to the server, and
encrypting the data stream. No coding necessary on the part of the
developer.  However, since in FM each file combines coding and data in a
way no SQL system does, data separation becomes something that DOES
require effort on the developer's part, unlike SQL systems.

I encourage you to download and explore the demo version of FM 7 from
the Filemaker site.  It is an entirely different development paradigm
than Access, with its own charms and maddening shortcomings. ;) 

Then, just for yucks, go to www.servoy.com, and maybe you can make both
your client and yourself happy. An extremely FM-like front end that
connects to ANY SQL backend. 

Lynn Allen
---
www.semiotics.com