08:40:49 PM
3HN18BQ2D
The only place to hang the user id and path is off _screen, and I am still not clear on your answer elsewhere, but it seems that _screen is not guaranteed to be scoped to the session. I guess it could be stored with get/setsessionvar. I have to see in the docs if there is a method that "cancels" or releases all sesson vars and resets the session, I imagine there is.
1. IOW, you are saying that only views are supported as .recordsource, never tables, cursors, etc.
2. the VFP docs I have say that requerying a view DOES reset the grid recordpointer, which is a deal breaker. There can be no visible change to the user after each request.
3. Why do the FAS docs say to use _screen for everything that was formerly "public' but is meant for that session? If I understand, that is not guranteed, and setsessionvar would be better,
Your .RecordSource can be a view defined by CREATE VIEW in form.Load()
Then reuse different base tables under the same aliases in wUserSet() and requery the view which only relies on Aliases.
View never being closed, .RecordSource is preserved and so are grid columns and their member objects.
October 2011 IP application worked that way.
I started a new thread to get out of the clutter and try and clarify. What is needed, and so far does not seem do-able, is something that meets these requirements:
1. Clients have data sets which are located in various physical locations.
2. The data source for the grid must be created with the client data once the client has logged in.
3. The data source for the grid must further be unique and scoped to the user session.
4. The grid must function smoothly and not get reset with each request it must appear to the user just like on a desktop where they can manipulate the grid at will, call subforms, etc. with no visible disruption.
5. The data can be updated to the master tables once the user selects to close the grid.
All this is not hard except for the fact that the grid makes it near impossible.
-Views cannot pre-exist since cleints cannot share data or database containers.
-using cursors or temp tables will not work because the data source is not scoped to the session
-so if you do scope the data to the session, it requires resetting the grid recordsource every request and every time any grid data is updated. That destroys the usability of the grid.
So far no proposed solution works, so I am open to all ideas.
