Hi,

Our software uses remote views to SQL Server for all data access, most of them parameterised.

Do you have a whitepaper, or similar, that explains how a form's data is restored each time a different web user makes a server request on the form?

I understand that FiC requeries remote views, but does it also make a copy of all cursors (local views and regular cursors also) and other open tables and restore them each time, along with their current recno, order, indexes, filter and relations?
.
If FiC requeries remote views every time a request is made to a form and the state of the data is restored, this is a very expensive operation in terms of back-end querying - every server request to the form, no matter how trivial, will cause all views used in the form to be requeried.

(In contrast, the form in lan mode will typically only query the data once when it is started up.)

Is there any way to reduce this overhead?
Perhaps define some views as needing requerying (ones with parameters) and others that do not?

If there is only one server being used, not a server farm, perhaps there could be a way of linking a form instance to a particular user session, so that it could remain static and not have its state restored for each request? Food for thought... 😉

Thanks
Paul

Hy Paul, If you want to use the structural and functional principles of a LAN application, in the same WEB application, you are wrong. WEB applications have their own structural and functional principles, often very different from those of the LAN, or incompatible with those of the LAN. Adapting a LAN production application, to make it work in WEB, requires to understand the differences between these two worlds and to accept them. All the success of such an adaptation lies in the discovery of common operating and structural points. You will need to modify or replace LAN-specific behavioral uses with those of the WEB. For example:

• in WEB you present to the browser only one HTML page (thus by similarity only one form Foxpro) and not the possibility of a set of forms as under Foxpro.
• in LAN a Foxpro application that executes only interacts with a single user / operator, while in WEB the same application Foxpro must interact with several users / operators. This involves saving and restoring the global and complete state of the application and the data directly manipulated by it for each interaction with a user. This backup / restore behavior of the environment of each user results in a slowdown of speed of execution between the LAN mode and the WEB mode.

In conclusion: For heavy LAN production applications, wanting to make them work on a WEB requires a good analysis of the needs of your customers and to check that the WEB mode is suitable for their needs. Here is the key to successful adaptation!

Regards Gilles

Hi Paul,

I understand that FiC requeries remote views, but does it also make a copy of all cursors (local views and regular cursors also) and other open tables and restore them each time, along with their current recno, order, indexes, filter and relations?

Yes FoxInCloud restores the data environment of a form for a given user before executing its request. We have described this principle over and over across existing FAQ and white papers. Data state is saved as XML in Temp\form_scx-*: browse for inlist(upper(pn), 'WITEMS', 'DATASESSION')

This is not at all an 'expensive operation', or should not be if your views are properly optimized; using SQLserver on a powerful server, only views with 10ks records should take more than a couple of ms.

Here is an example of a pretty loaded dataSession being saved and restored:

It's a VFP database however the 'WebTemp' CAD can have up to 30 parameterized filter conditions against the 270k records table. SQLserver should be far more efficient.

Here are the server's specs:

If you have complex views that take too long requerying a few records, and don't need them updateable and/or you can program the update yourself, you can use a cursor instead of a view; FoxInCloud will probably take much less time restoring the view's contents using XMLtoCursor(), and its buffer if any, than requerying the view.

If you have views that are NOT user dependent (eg. not parameterized), like lookup views, you can just add their alias to the form.wcAliasSaveNot coma-separated list.

Several other FoxinCloud developer suggested to implement user-specific form instances, and we have awFrm.wlPrivate provisioned for that. We could do that for VERY HEAVY forms, eg. with more that 2-3k properties to save (eg. GANTT chart forms), and/or many grids, and/or very complex views. So far we never had this need. Anyway it would have to be limited to a small number of users as the VFP name table could become soon overloaded and response time even worse than with a standard save and restore mechanism.

Hi,

Please don't take my questions as any criticism of FiC, it is absolutely not my intention.
I understand the conceptual differences between lan and web modes, I am now trying to understand the implementation in greater detail so we can refactor our existing code to be optimal, once we get past the prototype stage.

I have read many articles on the FiC web site and the blog site and if I have missed any previous discussions or whitepapers that cover these areas in greater detail I do apologise for this oversight.
The form.wcAliasSaveNot is exactly the sort of tip I am looking for to improve performance - thank you for this.
Where may I read about more details at this level?

My definition of "expensive operation" is really just any operation that has to fetch data from the server; we already cache data inside the application where possible to avoid back-end fetching and I am searching for more ways to avoid this - form.wcAliasSaveNot is a great example.
I know that I will be asked to explain to the infrastructure and data providers of our clients why there is an increase in traffic and server/database hits, so the more I know the better I can explain it 😃 Even more important when dealing with Azure SQL Database or similar.

Are you saying that awFrm.wlPrivate is implemented now, or just an idea for the future?
Where may I read more details about this?

Thank you for your patience and the detail you go into, I do appreciate it.
Paul

.wlPrivate could work only with both a single physical and logical server, a non realistic scenario: all FoxInCloud applications in production run with 2 servers or more.

However this process is optimized: FoxInCloud skips the restore step when the same user uses the same form twice in a row on the same server; the following table shows that (yellow arrow points to the restore time):