Does anyone have expericence with connecting/using hosted filemaker dbs via VPN (virtual Private Network)

I'm currently testing this and would appreciate any input/advice.

One of the main problems is connection speed to one of my main dbs which is a total of 21 mb.

i'm a bit in the dark if the db size is causing any problems although i don't think it will be although there are a few graphical interfaces within the database - any ideas?

Thanks in advance,

ricardo.

The 21MB size shouldn't be an issue at all. As for remote access to the tables, in my experience remote access speed depends on the bandwidth bottleneck, which is usually on the user's end. If you're on a LAN, life is good, but if you're tapping in via TCP/IP remotely, your biggest speed issue is the bandwidth. Basically, logging in remotely with anything less than DSL/Cable speeds is not worth the effort.

Two main ways to get around this are:

A) Keep layouts simple, especially lists, portals, etc. Do not sort or summarize unless absolutely necessary. Or at least, make summary fields optional viewing.

: If a pinch, log on remotely, but not through FMP. Use Timbuktu, PC Anywhere, Telnet, whatever. This is much faster, but perhaps only an option for developers and not Joe User.

i agree with what you've said. i have been stripping down a copy of the db which is to be accessed via VPN. i guess i will need to do this to all of the related dbs as well -

lots of inserted pics in there - i think this is where the problem lies

from what i understand the users will be logging on through an ISDN 64k connection so not much faster than a modem.

I am going to suggest to them about getting a designated line.

Anyway its Friday - sing allelulya.....umm i can taste that beer already!!

Consider logging users on via Web Companion instead of VPNs. I use the VPN system too, but only for external users with DSL or faster connections and the Filemaker Server is hanging on a 2Mbit dedicated-line. Even with this setup we have some problems, as there are also 14 users using the files directly over a 100Mbit LAN, so with say 3 or 4 external users, the bandwidth suffers greatly. Other users using ISDN (min 128k) are set up to connect using html over FMP

your setup sounds very similar to ours. We have 30 users connecting to our FM servers through our 100 mb LAN. Problem is our external users need to interact the same way in which our local users interact with the hosted db's.

So going via webcompanion won't allow this due to there been many scripts with sub scripts, many fields with calculations in the db which they will be using.

Going via VPN is also more secure then going via webcompanion

So looks like not much hope here apart from the ext users using a dedicated line. e.g. 2mb.

What do you mean by 'Filemaker Server is hanging on a 2Mbit dedicated-line'?

Thanks for your input - anymore would be helpful.

You could "distribute" the database, and synchronize all copies with SyncDeK:

http://www.syncdek.com

This way the external actually access a full copy (or a matching runtime) of the database locally including scripts, calcs, etc. Any adds/deletes/changes are synced in batch, or near real-time. And there's an interface for resolving conflicts at the field level.

what about editing over vpn? what are the risks if say the connection is dropped?

what about editing over vpn? what are the risks if say the connection is dropped?

Only total annihilation of your database.

That's only a slight exaggeration as the worst I've seen is the disappearance of the entire relationship graph.

You can do this, but I recommend having no users connected when you do and backing up immediately before you start work.

man thats close - have been doing this for quite a while now! will take heed thanks very much - so i suppose its the same if you were on the local network and the cable got unplugged?

We use Citrix to connect our users to our database. We have over 30 people connecting sometime and connection quality varies from decent (a slight lag and the occassional multi-second pause) to one of our remote offices that experiences intollerable slowness. I suspect it is a bandwidth issue at their end.