How many people are running FMS 14 in a production environment right now? I've gone through the forums, and not found a whole lot of complaining, but neither have a found a bunch of people saying they're excited to be on the new version.
As in not running, not excited.
We will stay on 13.0v5 at least till january 2016, on all our clients.
I'd certainly recommend "fixing what you have" rather than hoping that an update will magically correct your issues.
Weighing in on your system, you are definitely out of date on 13, all of your clients and FMS should be on 13.0v9. It sounds like your clients have failing network connectivity, you might want to do some packet sniffing and network load testing to see if perhaps you have some failing network hardware somewhere. If your system is designed to support remote/sketchy connectivity, then you might want to look into a hard coded sync solution, such as EasySync, GoZync, MirrorSync or others; so that the data lives on the clients, and syncs to the server.
The other possible cause is file corruption. You could create a new file and run some tests to see if the same symptoms present themselves. If you have corrupt layouts or corrupt data, it could manifest with symptoms in a manner you are seeing. Development on a live file is sometimes a dangerous prospect, but it seems like you're billing that as a feature of your solutions.
As for timeouts, this could just be an easy configuration in setting a timeout on your server. If you set a timeout of zero then it treats your connections as perpetual. One benefit of the FM14 platform is that the "attempt reconnection" is now a feature of FMP/FMPA, so at least it could help with your "communication error" hard disconnects. I usually default my FMS and file config to have a hard timeout of one hour.
My first thought was check your network, as well. You could have some bad switches or even cables or even network cards.
Run FM Pro on the server itself and test with some clients who have no issues. Then test with one who has an issue. Then:
- ping that client who has issues from the server and see if you have any packet loss;
- check (or swap out) their network card;
- swap out their network cable;
- run a treceroute to see how many hops there are in between the server and client;
- check the equipment that's involved.
IMHO, if you had corruption, it would possibly unilaterally causing issues, not just with some clients.
Making sure you have a solid network is extremely important, (especially if anyone is developing on the live file), because you could cause corruption to data and even the structure.
So I would seriously look into this. You might want to hire a networking expert from the outside to evaluate the network and all involved equipment.
Hope this helps,
Thank you, Agi and Mike.
We are pretty confident in our network - all Cisco L2 switches on each site, 10M MPLS from location to location, and enterprise-grade Aruba wireless everywhere. I won't rule out corruption of the databases themselves, however - we've had corruption issues with at least one database, which is still in need of some repairs. However, that database is the only one having problems, and is primarily used by iPad users - who DO have a nasty tendency to disconnect in ugly ways (while records are open, etc). We are VERY interested in the re-connect improvements built into 14 for exactly this reason. The long-term plan is for iPad connections to work with synced data, but it's looking less and less likely that it will happen in calendar 2015 - so we're looking for every advantage we can get.
I've seen the odd behavior where the local record doesn't match the server in two instances. One, on a FM13 LAN connected client (whose other network applications were running just fine), and the other on a VPN connection. Those two incidents are enough to tell me some sort of problem exists, though I'm not far enough along with troubleshooting to see exactly where it's coming from, and how networking plays a part. Next time I see it, I'll definitely check connections, but there's something fishy going on with FM Caching, as well.
We have client max idle time on the server set to 720 - long enough to kick off clients who disconnected "dirty", but not so short that it would kick out a client that had network connection issues. We did this in an attempt to correct the issues with the iPads that seem to not disconnect correctly. Some iPads have been known to create dozens of connections in the server, which can only be solved by forcibly disconnecting them on the server itself.
As for live-file development, we have little choice. We are using FileMaker as a corporate in-house solution for secondary applications, so developing offline and creating an update cycle would be overkill for 90% of our applications. While we have a large geographic area covered by our company, our user base is relatively small (200), and the number of people in any given solution is even smaller (5-10 concurrent for most solutions).
All of that said, it's interesting to hear everyone jump in resoundingly on network issues as a root cause. I will definitely keep my eye on connectivity as we continue troubleshooting.
None of that, however, pushes me away from going straight to 14 server. If anything - if our network truly is the source of our troubles - the re-connection improvements in 14 make me more interested in taking the plunge. I have a hard time believing that the core engine in 14 server is that much different than the one in 13.0.9.
The main reason to focus on network issues is the FileMaker Client/Server connection is a persistent connection and even a short drop and you loose connection, which has been a real frustration. But as you noted, FM 14 now allows for reconnect where you left off.... assuming someone else hasn't subsequently edited the record. But its pretty slick how it works. Its nice to be connected to a network, shut the laptop, go home, open it up and just hit reconnect. Also, it prompts you to reconnect and if you say yes, it will try only once to reconnect and then bail out. If you don't respond, it will automatically keep trying to connect. So not responding to the request to reconnect is often best and let it just make the connection on its own as soon as it can.
I really like Mike's suggestion of trying to fix and find out what is wrong before upgrading because if you upgrade, there still may still be an underlying problem. When in that situation though, I'll sometimes set up a test server to see how things work in the newer version. But the focus is on fixing the original situation.
I've had a very solid commercial grade network taking down by some staff person who, without permission, stuck a router on the network to try to solve a printing problem and it was blasting the network to a slow crawl. Everyone was blaming FM for being slow until I pointed out that so was printing, file sharing, etc. We slowly narrowed things down with a lot of testing and the sheepish user who put it on the network was one of the loudest complainers about the network going so slow. Oh well, lesson learned.
FYI, I'm very knowledgeable in FM, but I have no formal training and only in-field experience with networks. So I have teamed up with another company that specializes in networking and when those problems come up, I just send them over to them. They have all the testers and understand the 7 layer OSI much better than me. I think FM developers sometimes get sucked into being asked to solve problems where they are not the experts and need to educate customers that a single developer can't solve all computer problems. Its good to be honest and up front with customers on where you skills are and are not.
If you have issues only with one file on a server, than most likely the issue is with that file itself.
Until you provide us with more information we are all just shooting in the dark, trying to give you possible answers.
But if that file is used from different network nodes, that could be a problem, too. Or the constant disconnection.
So, yes, while upgrading sounds enticing you still may have the same issues. So, I would start with testing that file. Also, while at it, make a compacted copy of it and put that back on the server. You'll be amazed how much smaller they can get.
And, I think a lot of times we have no choice but to develop on the live file and nowadays with the fast and reliable networks that's not an issue.
Hope this helps,
I really screwed up with this thread, I'm afraid. My intent was to find out what the risks/rewards might be for installing FMS14 very early in its lifecycle, but instead I asked specific questions and muddied the waters.
I have another whole thread dedicated to the issues I have with our Maintenance Management database. I don't expect FMS14 to make the issues with that file go away - I have to clean that one up myself, and it's not pretty.
My questions to begin with should have been:
1. Is anybody running FMS14 in production?
2. If so, what led you to do that?
3. If not, why not?
4. What advantages do you see in FMS14 that make you want to get fully onto the platform?
Truth be told, we also have several projects in the pipeline, and I'd really rather not have to go back and re-develop them in 14 later in order to take advantage of all the good that appears to come with it.
Thanks, and I apologize for the misleading start to this thread.
It's worth noting, even though I'm sure you know this already, that FMI support essentially stops at FMS. While an annual maintenance agreement will get their technical prowess extending beyond this, there is also a very good reason for why this exists: everyone's network is different, has different issues and way too many variables for those of us well-versed as FM developers to even begin to get into!
I recently updated one of my clients to FMS 14 that handles 20+ databases for around 200 users (not concurrent). Thus far, they have been very happy and excited with the transition. The end users have been very happy with the updated UI in FM Go 14 and happy end users are more productive end users, so I have nothing to complain about. FWIW, being able to lock orientation is stellar and it's such a simple feature, but it works fluidly!
Personally, I'm enjoying learning the ins and outs of FM 14 and think it is a step above what the transition between 12 and 13 was. While not quite as different as iOS 7 was to many iPhone users, it certainly is a little different (script workspace, anyone?).
My two cents.