[KLUG Members] Re: programming question

[Adam Tauno Williams]

> The users have full access to all fields of the tables at all times
> to change any data in any table.  The structure of the forms (layouts
> in FileMaker lingo) is such that we cannot lock any fields at any
> time if we ever want to do a find on them without duplicating every
> layout and creating a find routine for them and even then the users
> can easily get around that.  Obviously data integrity is right out
> the window currently.  

Any of the current RDBMS systems will let you protect tables at the
backend level via GRANT/REVOKE.

> Believe it or not though auditors have said
> that this is one of the best systems that they have seen!  

Yours are kinder than mine. :)  But I'm also not surprised, 
applications designed for sites with sub-200 users tend to be total junk
in regards to data management, concurrency, etc... just because you can
get away with allot of cheating at such a low transaction volume.

> The report writer in FileMaker SUCKS!  To do calculations and sums I
> need to create fields in the database table that will do the
> calculation to be able to display it on the layout or report.  The
> ODBC connectivity in anything before FM7 is not worth talking about
> at this point.  The new FM7 Advanced server that is suppose to be out
> next month is suppose to have full ODBC functionality.  FM7 also puts
> multiple tables in a single file finally.  FM7 will also give us more
> granularity with locking fields in layouts and still be able to do
> finds on them.  We could do the work in FM7 and that is a possibility
> but we will be paying $7000.00 for the upgrade, which for this place
> is a lot of coin.  

$7,000 for an off-brand DB?  They're nuts.  You could license DB2 for
that much money.  Of course they're also bundling their goofy
development environment;  Informix used to do the same thing.  I think
your right in looking at separating the client and the database (one in
RealBasic, liked via ODBC to <insert Db Here>).

> I kinda like the possibility of PHP but don't think that I could get
> all the functionality that I would really like in the system. 

It isn't a zero-sum deal.  You can write one or more local apps, and
provide some functionality via an intranet.  Just use whatever solution
is most appropriate.

> I do know that if I can pull this off and get a working program from
> this that eventually they want to put a billing module in this too. 
> But I do not think that will affect the selection too much.  I think
> they want scheduling too and that might affect the selection. Hmmmm
> so much to think about.

Ick, writing scheduling apps is a nightmare.  I'd look at integrating
the scheduling part with something that already does scheduling
(Outlook, OGo, something....).  The feature set of anything to do with
scheduling is infinite and it always starts out with 'we just want to
do....' and balloons from there; just my experience.