1 of 1 people found this helpful
When you say local I would assume WiFi of some sort?
LTE upload speeds are not the best to begin with; better than 3G, but nothing compared to wired internet. I may suggest looking at your solution and possibly designing it similar to an iOS layout and schema. You can still use the layouts in FileMaker, but remove any non essential items such as large graphics, etc and review your schema to ensure that only the data needed is being transferred.
Thanks for the quick reply.
By Local I mean on the WIFI network provided by the router getting the internet connection from the LTE (which I just found out as a SPRINT product, is really WIMAX). The server machine (mac mini 2011 os 10.7) is connected by LAN cable to the router. Verizon's 4g does not let your host be seen without a $500 public IP investment, so that is out of the question.
The remote actions that were slow were simply performing a lookup from a pricelist (2900 records) by upc in a table within the same database, or switching layouts (form view--1 record rendered). No complex graphics--rectangles. I will try to create an even more pared-down layout and see if this helps. Stay tuned...
Another question for you:
How many fields in your table that you are trying to pull the data from?
32 fields in lookup table (product list)
35 fields in destinaltion Master table (Sales transactins)
29 fields in portal table (Sales line items)
--about 5 line item fields get lookup values from upc scan (style number, brand, description, unit price, qty
That is not much at all. I thoughts would be that the LTE is not obtaining the full speed during upload and therefore causing the issues for the users connecting via LTE. Can you run a bandwidth speed test from the server and let me know what the speeds are.
1 of 1 people found this helpful
For fastest and most limited caching requirements, be sure your layouts are in Form View, not list or table (either of which will require several times as many records to cache before displaying).
Also note that caching involves all fields in the table (except unstored calcs and containers, when neither is displayed), not just the fields on the viewed layout. So how many fields are in the tables involved?
Keep in mind that displaying related and portal fields trigger the same caching from those tables.
Tests reported at DevCon indicated there are some items which take 10X or even 100X as long over WAN connection as over LAN connections. All WiFi connections are WAN, even if the WiFi network-generator is locally wired into the modem/router.
One solution we use is to test the IP address of the client machine, and switch to a simplified layout if the client is not on the local LAN router for the server network.
Another solution we've used is to update data into stored local fields periodically (via scripting) so that the WAN layout fields show only local stored data from the layout's base table (even though it was set via script based on related or calculated values). Once it is local stored fields in the base table, the caching is much faster.
The simplified layout does help--Thank you. I also changed the host's router to allow the maximum upload bandwidth (don't know if this did anything, but I didn't want to take any chances). Looks like I need to do a lot of simplified layouts, and avoid lots of tab control fields. Still slower than I would hope--especially @ initial client login, but much better now.
ptrc, This also helped--removed most graphics. Uglier but faster now.
Yep, non-FM-native graphics are just one more type of data that has to move across the WAN.