John

All users do not need to live with the constraints that IWP imposes. However, if you give FMP users functionality that is not available to IWP, then indeed you need some strategy to separate the two users. One way to do that would be simply to branch scripts appropriately, as you suggest.

However, it is probably more efficient and easier to program if you completely separate the two functionalities. You can have IWP users access completely different layouts (designed to be more appropriate for web users). Buttons on those layouts can be linked to completely independent scripts that provide the more limited functionality. You can name your layouts and scripts appropriately – using say a "iwp-" prefix for layout and script names associated with IWP.

The underlying tables (and therefore data) are the same, but the whole user interface is separate. That seems to be what you are after when you talk about 'two linked versions'.

If this is still not enough, you could always put all the IWP functionality in a completely separate file. You place table occurrences in the relationship graph from your 'main' (ie FMP) file, thus ensuring that the same data is used.

You may have read about the 'separation' model of Filemaker development, where there is one file containing all the data tables (but no or minimal scripts and layouts) and another containing all the interface elements such as layouts and scripts? I have used that on at least one occasion with multiple interface tables: one for regular FMP, another for FMGo, and another for IWP. This makes it much easier to manage these multiple methods of accessing the data. The disadvantage though is that sometimes a function has to be written or modified in three different versions. Still, since FMGo and IWP are so different from FMP, a similar amount of work might be required even if they all used the same file.

Does that help at all?

Steve

On 7 Sep 2011, at 14:40, John Eiseman wrote:

> Having informed my client that IWP precludes the use of some script steps and some strategies, he responded that he would like me to develop two versions of their solution; one for access via IWP and the other for in their office via Server access ... yet have the two linked, accessing the same data.  Most of their users are in the office. The client doesn't want me to 'dumb-down' his solution just so that a couple of remote users can access via IWP.
> 
> Rather than have two linked files, I suppose I could have just one solution and every time I reach a point where I'd like to use a non-web script step I test the user, and if he's accessing via IWP, then I execute one set of steps, and if he's not, I use a separate set.  But it seems that this would be very inconvenient to program.
> 
> I'm basically an amateur and don't know if two linked versions is possible, at least not easily.  Therefore, I'm hoping that there's a better way of accomplishing what the client wants that I'm unaware of.
> 
> If a client needs some users to access via IWP, must all users live with the constraints that IWP imposes?
> 
> Thanks for any advice you can give me.
> 
> John Eiseman
> St. Louis