Re: Cursors and closing thereof

For this reason I actually tend to use the same cursor names with any queries that don't need to persist things (I like TQuery as you might have surmised from demos :-).

But as pointed out by Ian and Stein - if you do have to close cursors you can do this either with RegisterCursor() which effectively close cursors/tables added when the page is unloaded or by maually overriding the Dipose method to do whatever you need to:

FUNCTION Dispose()
DODEFAULT()

USE IN SELECT("MyCursor")
USE IN SELECT("MyOtherCursor")

ENDFUNC

+++ Rick ---

Stein & Ian,

Thank you for pointing me in the right direction. I think I now have a handle on how to close these cursors assuming that my user will actually use one of the buttons I have provided to navigate to a different screen.

If they are done using my web app can simply close the browser it doesn't look to me as if there's any way to know that they have left. In this case I will have no trigger to close any open tables. Is there a workaround? If not, what happens over time as people come and go?

I did look at the documentation about RegisterCursor and that made sense to me, but it referred to a method called Page.Dispose(). I saw no reference to that in the documentation. It is a custom method that I would have to add to the page?

Thanks,

Potter

Just close the temporary cursors at the end of the same process method where they were created. e.g.

SELECT whatever FROM someTable INTO CURSOR tempCursor

...use above info to populate forms/grids

USE IN tempCursor

Because of the stateless factor, you can't carry those cursors from one hit to another in any case. Whether or not a particular visitor has "left" is irrelevant...

--stein

Rick,

Thanks. I think I have structured the app to operate in a stateless manner (you finally got me to see what that was). My concern now is how to close the cursors created by visitors. Since I can never know when they leave, I don't see how I can close these files.

Potter

To access the site each user must login and I validate the login information against data in a FoxPro table. Once access is granted I provide access to information primarily by running queries, producing cursors and displaying the results in either a form or a grid. While this all works I'm not sure how Westwind handles multiple users. The query is producing a cursor with the same name each time that piece of code is hit. Does each user get their own set of temporary tables? I do not presently have a logout button so I'm not sure what's happening to the temporary tables created by a user visiting the site.

Web applications are stateless which means every hit is a new session effectively and it's your responsibility to restore the appropriate environment on each hit. This is why every request typically has some sort of ID that and action that tells the backend what action to perform and what record or data to perform it on.

There's no 'database session' for a user. Each hit is a new session and it's your job to "re-attach" to a session on each hit. This means that you need to keep track of the users state either in the database or using the Web Connection Session object. IOW, you as the developer have to track state.

Effectively this means that on each hit you have to restore the environment you need to run your logic. This might mean re-loading the user data based on the user's ID. THis might mean reloading the customer data that the user just entered to update it when they click on Save. Stateless programming basically means that every request has to be self-contained and set up its environment on each request.

A couple of weeks ago I mailed a letter and check. The check is not engaged in I wondered if you have received it

Got it. I'm not very good about putting checks into the bank quickly :-).

Aloha,

+++ Rick ---