1 of 1 people found this helpful
Sure it is, but note that given the distance and latency that comes with that, making schema changes can be dangerous and can corrupt the file.
1 of 1 people found this helpful
Wim is right -- latency will impact upon the risk of file corruption.
In my experience the risks are greater when making modifications in the Manage Database area, than if you modifying scripts or layouts. Field and Relationship mods are best undertaken when all users are logged out of the file AND you have a recent backup for when the connection is dropped whilst saving the changes.
I hope this helps,
Thanks for the confirmation and the advice.
As a matter of common practice, we only edit structure elements when the users are off the system, I do appreciate the comments about latency. I did some experiements and was a little surprised at the performance, better than I expected. The purpose is to provide an alternative for some quick response maintenance activities.
I have been doing exactly this for a number of years (knowing the risks) and have yet to have any problems that have necessitated rollling back to a previous (hourly) backup. I don't, as a rule, make schema changes when others are working on the DB, of course. YMMV.
Recently I had a client that insisted on development of a new solution hosted on the clients server. I did this and other then more latency then working on my local server everything was ok.
I had a chance to discuss this with an FMI representative at the recent Pause On Error conference in Portland. He told me that FMS 12 has more immunity to corruption caused by network drop outs then previous versions due to the way it stores the changes and only committs them when you exit the layout mode or the relationship graph. If the connection is lost, it closes the connection with out committing the changes so less chance of corruption. He did say that FMS was not completely immune to these problems, just less susceptable then earlier versions.
If possible when working on a remote data base I try to use some form of terminal emulator like Microsoft Remote desktop so that the connection between FileMaker and the database is a local connection. If my connection to the remote desktop is lost, I reconnect and FileMaker and the database is unaware of the loss. So no damage.
All of the other warnings about working on the database when no one is in it are still valid. Even if everything works as intended, saving a layout with Tabs will put any user using the layout back on the default tab. This at best can be disconcerting to the user,
Thanks for the detail Bruce.
Your description is exactly what I have been doing for years to provide remote maintenance. I have never tried to directly connect to a remotely hosted solution before because I always had a workstation at the host end.
This new request of us does not have the workstation availble at the host end in a reliable way, so I thought I would experiment with a more direct method.
Taking all of the normal warnings and precautions aside, I am pleased with the ease of use of this direct method, it will help us out alot, because the host end is 3 time zones away.
Thanks for the feedback.
One other thing to keep in mind (for those that have not thought about it already): a lot of companies have policies that prohibit TCP/IP 3389 (Remote Desktop Connect or RDC) from being open for security reasons. Having FM Pro Server accessible thru the firewall at TCP/IP 5003, at least in my experience, is an easier sell. A VPN connection thru the firewall is, of course, the better way, if it is an option.
I would argue the reverse. It is a lot safer to allow RDP than to allow a direct FM connection through the firewall. Most companies I work with (including banks) are ok with RDP/citrix/TS connections because they can leverage all the OS hardening options that are available. Whereas a 5003 connection directly exposes the traffic and puts ALL of the security onus on the FileMaker product line. And that's not something a lot of big IT departments are comfortable with.
Both wimdecorte and Mike make a good point. In our case we have a secured IP tunnel between the two points, the host and the remote station. This actually allows us to use either method, or, in my case, both methods.
No offense to FM but I would also not want to put all of my security expections on the FM product.