AnsweredAssumed Answered

I have dug myself a hole. What's the best way forward from here?

Question asked by stuart91 on Apr 21, 2017
Latest reply on Sep 30, 2017 by Malcolm

I'm looking for advice on what to do with a Filemaker system that I (try to) manage. It has been built over a number of years, and is intended to keep track of an equipment rental business. Since we are a relatively small concern, it has always struggled for attention. Maintaining and improving it is not even close to being the main part of my job, so my focus is often pulled elsewhere.

 

A while ago we decided that we would abandon Filemaker and move onto a proprietary cloud-based system, that has been specifically written for the rental industry. Whilst I was partly saddened to see many hours of work put aside, I was also quite glad that I wouldn't have do any further development work on our Filemaker solution, as it has become bloated and confused over the years.

 

The problem is that, despite some promising early results, all of our staff hate the cloud-based system. It doesn't fit our workflow very well, so it feels cumbersome, and lots of basic things that we are used to doing in Filemaker are now impossible. The additional features of the cloud-based system don't make up for the loss of speed and simplicity.

 

We've been trying out the cloud-based system for a couple of months now, and today it was pretty much decided that we will be going back to Filemaker. However I've been given a "wish list" of improvements to try and tackle in the coming weeks/months.

 

My challenge is that, basically, the structure of the database is a mess. I can count fifty table occurrences on the relationship graph, out of 13 actual tables. There are dozens of relationships, most put into place to make a particular portal work, or as a hack or workaround. I suspect I've missed something fundamental with relationship tunnelling, and bodging my way around the problem has added too much complexity. There are lots of workarounds and techniques that must have made sense to me at the time, but are now quite difficult to follow.

 

Whilst I could try and simplify the relationships, that's going to be a huge amount of work, because there are countless instances in scripts, calculations, and conditional formatting where field names would need to be changed. The amount of troubleshooting required will be ghastly.

 

It's enough to make me consider starting again from scratch. I could probably copy a lot of layout elements etc. but it would still be a huge amount of time. And I'm not convinced that I won't end up in a similar mess, and come to grinding halt again, maybe a little further down the line.

 

It wouldn't be out of the question to hire a developer, but I'm not sure if anyone would be too happy with a job that is essentially replicating an existing solution and interface, but with better arrangements under the bonnet. Plus would be realistic to expect anyone to be able to work out everything that's going on in the existing file?

 

Are there any third party solutions that can help "map out" a database in a bit more detail, and show what relationships are used where? If I could automate some of the troubleshooting then it might be easier to tackle.

 

I'm open to any suggestions - let me know what you think.

 

I've attached a screenshot of the relationship graph, which at least should give everyone a laugh.

Attachments

Outcomes