Jump to content
The ORIGINAL FileMaker Community - Forum - Online Business Apps & Software Forum

Recommended Posts

elkpodemiami

Hey everyone, The company I work on has a legacy system on Filemaker Server 5 and Filemaker Pro 6 / Developer 6, As you guys know each database is a table in the new filemaker versions, I have issues with certain files, I don't know what to do, when navigating from 1 DB to another one based on relationships some relationships became unstable in a way that they freeze and takes longer to to go related records.

 

This wasn't happening before and I'm sure those relationships were not modified or anything, I actually believe that the files themselves might be kind of corrupted.

 

I have tried

 


    Copying the main DBs and replacing them


    Saving copies as compressed (smaller)


    Restoring the main DBs

 

None of these fixed the issue, I don't know what else to do, maybe there is a tool or something missing that can check for the actual file health or indexes or something?

 

I would appreciate any information since this is crucial for the company, the solution is working very slow and I'm running our of ideas.

 

Thanks in advance

Share this post


Link to post
Share on other sites
Ross MacLane

I would suggest upgrading to the latest version of FM immediately rather than beating yourself up with this nightmare and running into even more issues trying to resurrect your database...you would be doing your company and yourself a huge favor.

Share this post


Link to post
Share on other sites
elkpodemiami

That would be ideal, but the solution is way too big already that for a simple person to migrate the solution into a new updated version can take way too long speacially considering that now everything is way simpler and easier. I'm talking about 100+ .fp5 files.

 

I told this to my boss a few years ago but he insisted on keep going, now it's chaos but I need to find a way of fixing this.

Share this post


Link to post
Share on other sites
AHunter3

I converted one consisting of 454 tables, rebuilding from scratch, in 2006.

Share this post


Link to post
Share on other sites
Maarten Witberg
None of these fixed the issue, I don't know what else to do, maybe there is a tool or something missing that can check for the actual file health or indexes or something?

 

I would appreciate any information since this is crucial for the company, the solution is working very slow and I'm running our of ideas

 

As Ross and Alan have said, it may be wise to invest in a complete overhaul wich may cost $$$ now but will save many more in the long run because your database has become unmanageable and will damage business. It may be wise to seek independent advice before taking that step.

 

 

Nevertheless, that scenario could take a couple of months to complete so you may investigate several ways to optimise your current solution.

 

If you are a technet member you can download a guide on how to enhance performance (it's written with the latest versions in mind, but the core concepts hold for v6 as well): http://www.filemaker.com/company/media/press-releases/releases/2014/filemaker-offers-free-guide-to-designing-high-performance-filemaker-solutions.html

 

Before attempting anything, create a backup of the entire solution. I haven't worked with version 6 files in years so... but I am hazarding a few guesses that might help speed up stuff:

 

- the indexes of the foreign and/or primary keys may need to be rebuilt -> use the first set of instructions here: http://www.filemaker.com/help/12/fmp/html/recover.40.12.html

 

- the related sets of records have become very large which leads to lots of back and forth data traffic between server and client, for instance if you're habitually showing portals that have hundreds of related records or more and lots of calculations in them. It's not really possible to tell if this is the case without seeing the solution. But you can experiment with this. For instance if you're showing ten years worth of invoices for a client in a portal, you could limit this by showing only the invoices for the past two years for instance. Then if it is necessary to create multiyear financial overviews you could create a scripted way to retrieve that info. A more radical approach may be just to archive a lot of data, but you need to be very careful doing that of course.

 

- layouts have become very complex over the years so with each screen refresh a lot of stuff has got to be updated. Use the script step Freeze Window in any and all scripts liberally. It will prevent screen refreshes that you don't need for instance when looping through a long list of records.

 

- Can the tree be pruned? look critically at those 100+ files. are all of them still in use? Are there redundant or obsolete relations that may lead to unnecessary data traffic?

 

- look at potential hardware and OS issues. Version 6 was released in 2002, your hardware probably is more recent than that.

 

 

edited-in afterhoughts:

-- sort orders in portals may be off. if they are set to sort by a related value (or even an erroneous sort setting used by copy-pasting) stuff will slow down

-- summary fields that have to be updated for a large set may also cause a performance hit, so limit their use or script their update on user request. put a global field in the layout and remove the summary field.

Edited by Maarten Witberg

Share this post


Link to post
Share on other sites
This thread is quite old. Please start a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.




×
×
  • Create New...

Important Information

Terms of Use