Our  Certified FileMaker 7 Developer  is Steve Morrisby – Bidmuthin’s founder.

As well as systems based on the Bidmuthin Management System, we also develop other systems (see below), work as sub-contractors for other companies, convert , migrate and / or re-write from v3-6 to v7/8 (more…), troubleshoot existing systems and provide advanced user-specific FileMaker training .  And we support.

Click here for more about the BMS

Some Other Systems

Although most of our FileMaker development is based upon large comprehensive business systems; sometimes we do other types if it’s interesting.

Here’s some examples:

Mail Order vitamin company

(note to self:  put story in here)

Encyclopedia

Problem:

A publisher of a book of Architects data (they called it an encyclopedia) wanted a cheap way of enclosing a CD which would contain all the data in the book but in a searchable format.  It had to be cross-platform and idiot proof and cheap.

Solution

FileMaker has excellent text indexing and searching facilities. And is cross-platform.  The Filemaker Developer Tool  creates stand-alone distributable databases.  All that was required was a consistent layout, enough find and sort buttons and to make it fool-proof.   And FileMaker's good at that too.

The neatest solution

Clearing Bank Automated printing

A major clearing bank uses approximately 200 internal forms.  These are not glossy brochures but A3 and A4 (or smaller) single colour forms, such as memo pads, standard letters and so on.  The problem arose out of the need to not only personalise the forms to  one of  6,000 personlisations (branches; managers) but the fact that the positioning of the personalisation could vary depending upon the data.  (yes, really!).

The current approach was too slow.  It was taking around two man days to do the days work of creating 300 forms.

The main-frame guys had experimented for about 12 months with calculated mail-merges - but whilst mail-merge is great at putting different data on the same form, it's not so good at splitting between different forms.  So that hadn't worked.

Solution:

FileMaker, of course, was the answer.  By setting each form to be a FileMaker layout  and by setting up some calculations to switch layouts depending upon the form request data it was able to produce output as fast as the printer could take it. 

Later it was upgraded to handle different types of printing.  Form requests are collated from around the country at central puchasing. The data is transmitted electronically to the print works where FileMaker  now not only prints the form from which the plate is made; but sends some to a "print-to-plate" machine, yet others to massive 80 page per minute Xerox docuprinters.  Not only that, but because FileMaker has been so reliable it even prints out the purchase orders for all the other jobs.

A troubleshooting story

This is my favourite FileMaker story, and I usually tell it either as a rant against how the government wastes money or how stable FileMaker can be.  So this gives me a chance to write it down.

It all started around spring 1999 (the year is significant) and a round-robin was emailed through the filemaker community asking for ideas on a large FMP solution which was crashing a lot.  I made a couple of suggestions which apparently did a bit of good and as a result got invited in to see if further improvements in stability could be made. So off I toddled to Canary Wharf to see the system.

What I found was the biggest FMP system I'd come across:  It was a 130 seat solution  (there was a 100-user limit then, but on average only 78 users were active at any one time.) of around 40 files.  There was no full time FMP Developer - even with a 130 users they couldn't afford a proper developer (they said) leaving one young chap who was quite interested in it to do the best he could.  They were still using FMP3 - because, once again they couldn't afford the upgrades  (they said).  (There had been a falling-out with the original developers so they weren't around)

There were 3 main files, each of about 600,000 records and 600Mb in size (in essence representing Yes, No & Maybe) each with around a hundred layouts & scripts.  Basically, each record was a person and tracked a potential value.  As such it was tracking a lot of value (just how much I'll save as a punchline) and the data was valuable. Each of these files had around 300 fields, a password list that kept scrolling for ages and I gave up on the value lists. Plus 30 to 40 relationships, many broken.  The subsidiary files varied hugely in all respects but multiple relationships abounded everywhere.  To make matters worse, at some point in the past someone had copied one of  the big files with no regard to relationships but so that it held less than 50 records.  And they had done this not once but six (SIX!) times.  In short the whole thing had gotten completely out of control and was a MESS.  What's more the users were having to do finds up to 7 requests deep on unindexed fields;  and these finds could take a couple of hours And what was FileMaker server running on:  on a 200MHz Pentium Pro  (that's the chip between a Pentium and a Pentium II).  (yes, really)

To shorten the story a bit; you can imagine my surprise when upon investigation it turned out that this poor little server, in addition to running the filemaker system, was now also testing a 500-seat email system!!!  This, in case you didn't know, is the equivalent of  having half a dozen bricks in a washing machine.  Once we had persuaded the IT dept to remove the email system , things improved dramatically.  And when we also persuaded the IT department to stop turning off the server without warning people properly, things improved even more.  From crashing 3 times a day to about once a week

An initial report was produced, with some Oracle guys suddenly appearing out of nowhere taking a keen interest.  (As if they were hoping to rewrite it in Oracle - but they couldn't afford a Filemaker developer on staff? .)  We displayed the main ER diagram - a sheet of A3 with Lots of lines. "Coo" said the Oracle guys (actually they said something else) "we didn't think FileMaker could do this level of complexity.  This is Oracle territory".  "Wait", we said - "that's just the main ones.  Here's the overlay with all the spare, unused, useless and broken relationships" and a second A3 sheet covered in lines going everywhere  was produced. "If we'd put these on the same sheet the main ones would have been obliterated".  The Oracle guys went very quiet. " Oracle won't tolerate that sort of mistreatment", one said.

I then went on to explain that crashing once a week (whilst some of the people there were considering that acceptable - given the past history) was totally unacceptable in FileMaker terms  (even on a 200MHz Pentium Pro).  The crashing was caused by residual corruption in the database files from when the server had been being switched off with people still logged in and simultaneously running email. (They had some lovely corruptions:  ever see graphic images printed out in a Define Fields listing?  Ever had a script that won't open, won't run but if you print it the machine crashes?  You get the idea.)  There were, of course, no golden backups and a re-write would be the best thing.  Sorry, not enough money for that was the reply.  But we do have a budget for the Year 2000 problem.  Could you report on Y2K issues on the database and at the same time remove the corruption?  Without changing anything else. Well yes we could.  (I should point out that we were being well paid and the Y2K budget was sizeable).

Well the upshot was that with a bit of effort the corruptions all got removed.  The database stayed on the 200MHz Pentium Pro and after a couple of months without a single crash the final bill was put in.  And was paid promptly, with thanks, and a promise that should anything arise / go wrong / occur then they would be in touch.

After six months of hearing nothing, we called them only to be told that everything was fine, no problems and if there was anything they'd call us.  And that was the last we heard from them.

Now the first moral of this story is that FileMaker can be incredibly reliable and robust and will tolerate dreadful mistreatment but there does come a point where you have to stop breaking it and start treating it reasonably.  The second is that FileMaker can handle pretty big data sizes - remember this was a while ago. Things have moved on a lot since then. And the final moral is:  To "do" FileMaker properly - whether troubleshooting or developing - there's more to it  than just FileMaker.

And the punchline:  I said "And that was the last we heard from them."  But I should have added… "apart from the newspapers."  The value held in that database  (the one they couldn't afford to have a full time in-house developer working on, remember) was revealed (a year or two later) to be 15 billion pounds.  (yes:  15 thousand million pounds !!).  It' was the Pensions mis-selling scandal database.

And that's just one example of how the taxpayers' money gets used by government.