Jump to content

Considering separating a large solution with MANY calcs [FMP11]


This topic is 4329 days old. Please don't post here. Open a new topic instead.

Recommended Posts

I've always been an advocate for a single file solution (or at least not he separation model) but now think that I may need to do it.

The reason: I have a shrink wrap solution and some of my customers have to run multiple copies of the same solution on one server. And some need to open multiple copies from one client. Part of the copy protection requires that the customer provide us with a unique filename when they purchase and that then also becomes the window name. Since FileMaker won't allow variables for related files, updating the solution will be 'hokey' and cumbersome. Any option that I can think of won't be impressive to the customer. Also, I'm considering the potential benefit of speed as some customers may have a server in the US and a user in China.

My concern: The solution has many thousands of rather delicate calculations in fields. I have about 4000 hours in writing just the calculations in this release (which is in late beta now). It also has very feature rich interfaces. About 75 of my layouts have over 500 elements including a great deal of conditional formatting. Most of the many thousands of calcs are dependent on the Evaluate function and in some cases, the calculation has to go back-and-forth between tables (from one to another then back again). The calculations (about 800 or so in the primary table) are in stored fields with replace existing calcs. There are also many hundreds of stored and unstored calc fields in the same table. Some of the stored fields are dependent on variables. And I do have thousands more calcs that occur in scripts as possible. What's in the fields has to stay in the fields.

Overall, I have about 350 layouts, about 3000 fields that have some sort of calculation in them, and about 400 TOs. There are about 150,000 elements total.

The solution is VERY clean and organized and the security could easily be modified for the separation model. I have a separate UI table with all my globals so my metadata (globals, licensing, copy protection, etc) is clearly separate from the user data.

The question(s): Does anyone have any experience separating something like this? I'm very concerned about calculations refreshing and the evaluate functions. Also, does anyone have any idea ABOUT how long it would take to separate? A few days, a few weeks, more? Is there anything special or especially challenging that I should watch out for?

I feel that the way the solution is now, customers will be very unhappy when they need to do an update but I'm also very short on time to get the solution out to market. If I have to do this, I prefer doing it now but I don't want to spend a lot of time trying then hit a wall.

Thanks in advance.

Link to comment
Share on other sites

Any feedback on any parts of this are appreciated! I'd be most interested to know what kind of speed issues anyone has experienced when switching from a single file to the separation model.

Link to comment
Share on other sites

Keep in mind that the aim of the separation model is to enable the interface to be updated without affecting the client's data, for the purpose of simplifying solution updates that only impact the interface.

The separation model does not aim to improve performance or simplify development, and it is likely that it has neutral (at best) effects on performance, but it increases the complexity of development significantly.

I did some sep work when the technique was discussed in the early days of FMP 7 & 8. Converting an existing solution was a lot of work. I'd take the opportunity to re-build the solution in FMP 12 using the sep model.

Link to comment
Share on other sites

Thanks Vaughan,

My concern is with the solution slowing down after separation. I don't expect to get it any faster.

I'll likely go forward and separate some of my tables that contain metadata into separate files to allow my to update those by simply sending out a new file. I expect I'll also separated my graphics table into it's own file and create another file for user's container fields. Short of some solid testing of the separation model, I think this model will give me the best ability to recover from corruption and speed up updates by avoiding updating any graphics. I guess this is a pseudo-separation.

Thanks again

Link to comment
Share on other sites

Anything other than a small project I always use separation. It can be challenging at times when using calculations and such but overall I would never implement a full system without using it. Management of data, reports, and UI updates are tons easier. Also with 12 and ExecuteSQL things even get better as I try to limit relationships in my data file to a minimum.

Link to comment
Share on other sites

This topic is 4329 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.