You may better not post your serial here...
And for a crash, better post a crash log as file, so we can read it.
Crash could be unrelated to memory.
Bill Gates denies saying this quote that will be attributed to him for all time, but whatever, it's still funny...
"640K ought to be enough for anybody."
1 of 1 people found this helpful
maybe not FMP fault - from my experience it is super stable - i am running 7 copies of FMP16 and FMPA16 the same time connecting to different files / servers. Never crashing and only 8 GB RAM and 2 TB SSD on i7 2010 MBP.
Maybe something corrupt on a layout or within a container to be loaded?
Also would check computer's RAM - maybe faulty RAM - if you have 32GB it can be the problem.
Actually he said 64k.
There's a feedback section for feedback. If you post here people will offer help.
We're have the suspicion of some degree of instability linked to the number of windows open as well, while developing (in Windows).
As yet we've nothing conclusive other than hearing 'not again' when working with a number of windows. We're always hyper sensitive having been bitten in the butt by a FM Active X bug from 9 years ago that crashed every (from memory) 16th window opened (not per person but 16 users, open 1 window each and the whole system crashed - killed a £30K project).
We're monitoring at the moment and the highest RAM usage we've seen by an FMPA v16 developer is under 2Gb, so not sure it is RAM related, but exiting FileMaker after a period of development (and script debugger/data viewer use) isn't a bad routine to follow at the moment.
However, we're not seeing the slow downs after periods of layout work that dogged v15 though.
Will update if we can identify anything conclusive.
Our solution uses over 40 windows/files, with no crashes.
Complaining about crashes is meaningless without a dump file. Could be anything from OS to plugins.
David, we're not complaining, we have a suspicion as stated but no concrete proof as yet. Over the last few years a number of our suspicions have ended up wirhin FileMaker update releases that fixed identified bugs as we gradually moved from suspicion to conclusion. For instance, a number of us on this forum identified that working for periods of time in layout mode eventually brought v15 to an workable state running on Windows, that was mostly resolved with later releases and to my knowledge wasn't an issue within Mac OS X. A dump file provided zero information in this case.
You mention 40 windows/files (you have my sympathy), but this may not correlate to using multiple windows whilst developing on a single files.
We're not suggesting that the operation for users is unreliable here, purely during design. And as has been proven in the past, what may be the case on Mac may not be the same on Windows and visa versa. Yup you're right about OS and plug-ins, which is why the time taken from suspicion to conclusion takes a good deal of time.
Actually, I would recommend you first do a quick Google search and you'll find many, many, many easy-to-find references like this one:
This wasn't about 64K; rather, this was the time where 640K was the directly addressable RAM without using memory extender utilities to get to some of that memory above the 640K limit.
Well...if you read the article, you'll see that Bill didn't say either thing. It's simply made up.
Sure, read it. But the point wasn't whether Bill said it, the point was the RAM amount that he's quoted to have said. Sure, it could be made up. The RAM amount in all the quotes is 640K.
This is silly to even be talking about.