wjmartin

Thanks for the response. Not asking you to write a Script for me but... could you give me an overview of how to implement this? WindowNames is not a Script step so I am not sure how to implement this.

The number (and names) of open Windows are never the same - so a Script that steps through known Windows will not work. I was trying to think of something 'out of the box' - ie: use a Script Step not really intended for that purpose. I tried scripting switching from Preview Mode and back to Browse Mode but again that only works on the frontmost Window. Is there anything more systemwide?

I work a lot with multiple windows open on the same Record. Something that is driving me mad right now is; I have a Field open in one Window and I try to edit the same Record in another Window. But of course I get the Record Locked message. Because I have multiple Windows open I have to go clicking through all my open Windows to release the Record - which is very irritating. I thought of making a Script containing the Commit command which I could quickly run with a Command-[Number] keystroke. But Commit only works on the frontmost window. Is there some workaround that would let me Commit the Record across all of it's open Windows?

It was v5. I ran the Security Update Ok - so here is maybe another question - is there any way that I can extract the older version of FMGo that is on my iPhone and install it on the new client iPhones?

I have tried accessing the FMS12 server using FMGo15. It sees the server but when I try to go into it I get 'No Files Available' (the server is set to list all DBs).

I have an instillation running FMS v12. There are existing iPhone clients but I now want to add some new iPhone users. The App Store only offers v14 and v15 of FMGo. How can I install an older version of FMGo so that they can access FMS12?

I have a FMSA 12.0.5 running on OSX 10.7.5 which needs the 12.0.6 update to allow FM-GO13 clients to access it. Every time I try to run the updater it hangs (the updater hangs). Specifically, it hangs at step 10 of the 11 steps. I have tried many things to get the updater to run and so far I am defeated. Does anyone have any pointers as to where I am going wrong?!

A strange one - I have a group of FM12 clients working off a FMS12, all Mac. When the users leave FM to work in other apps, upon their return to FM it is locked up. ie: nothing clicks, no menus pop down. The only fix I can find is to once again leave FM for another app and on the second return FM works again. Any thoughts on why this is happening?

I had this problem with FM12 and it continues on FM13. I have a script that reads (text to speech) a line of text just before it carries out a further action. I have found that occasionally this script stops just at the speech instruction and Filemaker crashes - spinning beach-ball of death, I have to force quit FM, relaunch and carry on. I use this 'speak and then act' approach on several different DBs using different scripts and this crashing behaviour seems to be associated with the text to speech. Does anyone have any thoughts on what might be causing it?

Apologies if this is a bit of an obvious question: I run a script across a found set to change the status flag of each record (The job can now be invoiced). This found set is itself defined by a status flag (The job can now be delivered). My concern is that while this invoice script is running, another user could be changing the delivered status and the script could miss a record. Is there a way to temporarily lock the whole database to everyone except one user - so that the script can be run without any other users modifying any data?

No, the email account is running perfectly on an email client app

I am struggling to get the email notifications working on FMSA12. I absolutely know that all the settings are correct and the email account is working fine on an email client program. Any clues as to where I am going wrong? Â Â

Ok - I got it. It is a Remote Access issue - connect an actual monitor to the server and you can then see the content of the Security Warning. Then you can over-ride it and carry on.

New install of FMSA running on OSX10.75 with Java 7-21 installed - Every time I try to open the Console I get a blank window labeled 'Security Warning', I close that window (because it is blank) and the Console does not launch! Help!

I got this excellent response from Lee PowerSlave over on thr FM-DEV Forum. I thought I would post it here (with his permission) to help others with similar questions: "FmGo 11 does work ok over lan as you have stated, but for better wan performance you should consider FMGO 12. Fm 12 has been redesigned with wan performance in mind and it really does make a difference. Another point to consider is to create a stand-alone interface file that lives permanently on your device and have it use a file reference to your hosted data file (seperation model). This way only record data will be exchanged instead of record data, layout elements and all of the other 'bits'. The net result should be to exchange as little data as possible, and by having the layouts stored on your device, graphic data won't need to be sent via 3G. There are other things to consider such as only showing fields thay you REALLY need, and try to use merge fields in list views instead of normal fields. Each one of these techniques will add up to a significantly faster solution when being used across a 3G network. I have done the hard yards and been through what you are experiencing and when you start to rethink your design in a way that 'less is more', you will start to see good performance using FMGO across a 3g network. Hope this helps, regards, Lee."

I have a longstanding .fp7 database which has been running for years on a FM10 Server. Access on desktop clients has been snappy and entirely satisfactory. There are 22,000 records, 380 fields per record (no containers) and the whole file is 300mb in size. I am now testing access to it using iPads FM-Go-11. I have not altered the DB in any way, the layouts are simple and work well on the iPad. Here is my issue. When the iPads are within the same wifi network as the server the access is a little slow, but just about acceptable. But when the iPads are taken offsite and accessing through the cellular 3G network the access is painfully slow. My question; Without being overly specific, are there certain general principals I should be following with my approach to iPad access? Are there some real no-no pitfalls that I may have fallen into? Any pointers would be welcome.

I did find a solution - though not as elegant as I would have liked - I added a Perform Find button to the layout. Strange though that the problem existed, without a Perform Find button the user remains trapped in a tabbing cycle!

I certainly did! Still the same behaviour - Find Mode is trapped in a loop of jumping from tabbed field to field, never allowing the search to be performed. If it helps, I tried copying the file onto the iPad and the problem remains even when the file is local to the device.

No - Custom Menus didn't work! I created a custom menu set that did not contain 'New Record' etc. and made it the default menu for the whole DB. But my iPad users are still trapped in a never ending loop of search tabbing! In Find Mode they can tab from field but the keyboard Go button never works - ie: they cannot perform a search! Where am I going wrong?! It works fine on the desktop machines - why not on the iPad?

Thanks for the response David. I will give Custom Menus a try. The choice of FM GO 11 is dictated by the overall setup. It is a .fp7 system running on FMS10 with several desktop clients running FM 9, 10 and 11. For now, I don't want to roll the entire system forward to FM12 just yet - that would involve clients, server and full testing of the converted solution, a lot of work just to give a couple of iPads access. I will go to FM12 at some point, but this is not the driving decider.

I have a .fp7 format file hosted on a FM10 Server. I am rolling out iPad access using FM Go 11. I have two types of user, powerful admin users and less powerful standard users. My users access the DB with both Macs and iPads using the same login. I am getting a strange behaviour in Find Mode on the iPads. My powerful users can open a search screen (via a script), enter data into a field, hit the keyboard 'Go' button and have their search performed - all ok so far. But when my standard users enter Find Mode they become trapped in a cycle of moving from field to field, ie: the keyboard 'Go' button has no effect - they cannot perform a search! I have looked at the two Privilege Sets and the setting that makes the difference is the 'Available Menu Commands'. My standard users are limited to 'Editing only', while my powerful users have access to 'All'. I cannot possibly allow my standard users to have full access to the menus, accidental COMMAND-Ns and they will be filling the DB with empty records etc! Any suggestions on how I can make their searching work on the iPad without allowing them to use the full menu set on their desktops?

This is a 'big' question so I am not expecting full answers - but I would appreciate some pointers to where I can get more info; I have a shared DB consisting of Job Records. Each Job has a status (ie: 'in progress', 'completed', 'invoiced'). The status of each record is updated individually, that is, I open the individual record and stamp it with it's new status. However, for the final status ('invoiced') I want to be able to open a list of all 'completed' jobs and stamp them all as 'invoiced' simultaneously. The problem I anticipate is that in the time between when I create this list and the moment that I stamp it's records as 'invoiced' another user on the system may stamp another record as 'completed'. That record will then not be included in the batch stamping. What strategies can be used to deal with this - ie: batch processing records when other users may be simultaneously modifying the very field that the batch is based on?

Is there any way to save file passwords to avoid having to retype them at every login?

Got it!!! File Options: Open/Close: Switch to Layout: I had not specified a layout, instead I had left it to the opening script to make the change. When I specify my welcome layout here the iPad opens instantly. Strange though that the iPhone did not have tis problem!

I have a large served database that uses an opening script to display a plain one-record welcome screen. It functions really well on my desktop clients and on my iPhone. However, on my iPad it is amazingly slow to open. I can see it opening a big complex search and sort layout, I get the red cancel slider and after many minutes of processing it switches to the welcome layout. My guess is that when the database was last worked on locally (directly with no server) I must have closed the file on that big complex layout. I thought the opening script would over-ride that return to the last used display. Is there a way to make it go directly to the welcome layout without all this unnecessary processing first? And why is the problem only apparent on the iPad and not the iPhone?