Session Timer expiration

[jking]

Bruce,

In a NT 11.24 app, users enter patient data.  Some of these users will begin, entering just a few fields and then walk away.  One field, PatientID is auto-incremented.  It is used to build another StudyID field, with an example format of D1-XXXX, where the XXXX is the PatientID.

In the ValidateInsert embed of the form, I construct the StudyID (if the user Saves the record properly).  If they walk away, when the session counter (15 minutes) expires, a record is created with the auto-incremented PatientID, but the StudyID field is not filled in.  I guess at this point the ValidateInsert method is not called.

So, is there an embed I can use to construct the StudyID when the session timer expires?  Better still, is there a way to prevent any partial record being saved when the counter expires, thus not using the next auto-increment value?

Thanks,

Jeff King

[Bruce]

Hi Jeff,

Sounds to me like auto-increment is the wrong ID for this sort of table in the first place.
Your other problems seem to result from using an auto-incrementing ID.

So my first suggestion would be to fix the root cause of the problem - and change the ID to a unique string identifier.
Would that work for you?

cheers
Bruce

[jking]

Bruce,

     This app already has unique string identifiers for each table (GUID's).  Users need to refer to specific patients at different institutions so I created the StudyID for them.  This is smaller and easier to deal with.  They can refer to a patient with "D01-1234" instead of "FHJKHFUYIUHFUIRX".
     So I'll ask this differently.  I would like to conditionally control if data is saved when the user walks away allowing the session counter to expire.  Is this possible?  How would I approach this?  Maybe I should also display a message telling the user their "partial" data was or was not saved when the counter expires.  How would I do this?

Thanks,

Jeff

[Tim]

This doesn't solve your problem directly, but this may be a helpful alternative.

I use a "Saved" column that is populated = 1 when the user saves the record (and all else is validated). Browses have a Saved = 1 included in the filter/select statement. If a user begins to create a record and walks away without saving: the Session is timed-out, the browser is directed to the login page, and the partial record is never seen by the user b/c the Saved column was not populated with a 1.

Of course, this affects the users if they spent a lot of effort filling-in information, walk away, and the record is "lost". I haven't had any difficulties in this regard, but my timeout is longer than 15 minutes.

[Jane]

     This app already has unique string identifiers for each table (GUID's).  Users need to refer to specific patients at different institutions so I created the StudyID for them.  This is smaller and easier to deal with.  They can refer to a patient with "D01-1234" instead of "FHJKHFUYIUHFUIRX".

Then you're half-way there, Jeff.

I worked for a number of years with a health records system that used a MS SQL uniqueidentifier as the "real" patient id, and all patient records were tied to that internally.
But it also had a human-friendly integer medical record number for display to users.

Instead of auto-incrementing the Patient ID when the user first starts working on the record, why not wait until the user actually commits to saving the record and grab the appropriate user-friendly Patient ID at that point and inject it into the record just before saving?  Tie the studies to the patient via the GUID but you can still display the Patient ID on the study.

Jane

[Bruce]

>> In the ValidateInsert embed of the form, I construct the StudyID (if the user Saves the record properly).  If they walk away, when the session counter (15 minutes) expires, a record is created with the auto-incremented PatientID, but the StudyID field is not filled in.  I guess at this point the ValidateInsert method is not called.

So you have an easy mechanism to detect form records that were not completed?
ie PatientID is constructed, but StudyID is not...
So presumably you could have a process to either delete these incomplete records, or fill in the StudyID?

I guess, I'm not yet 100% sure what problem you are trying to solve...
Do you want to not have these orphaned records? Do you want to have them (partially complete) but with both fields filled in?
Why are you priming on "Save" rather than say priming on "Insert"?

I guess none of these are answers to your original question - but I'm not sure I understand what you are really trying to do yet...

cheers
Bruce

[jking]

Bruce,

     My first choice would be to save the partial data, so the user can go back and pick up where they left off.  However, this is not working when the session timer expires.  Only fields such as GUID and Patient_ID, are saved at expiration. The Study_ID which is primed/constructed in the validate Insert embed, is not getting set at expiration.  If it did, this would be progress.  I tried priming the Study_ID on the Templates Priming tab (on insert), but it did not work.  So I added it to the Validate Insert embed.  Here is the code:
 
Enr:Study_ID = 'D'&Format(Enr:Institution_ID, @N02)&'-'&Format(p_web.GSV('Enr:Patient_ID'), @N04)

This would produce a Study_ID like:  D25-1234

A question here is, does the auto-incremented Patient_ID get set upon Insert or only at Save?  This might explain why trying to prime it did not work.

     You mentioned creating a process where the partial records are deleted.  I did this, and run it as each user opens the main browse.  This works well, but means the user must re-enter data. 

     I would also like to display a page to the user, if they let the session timer expire.  The message would be that partial data was saved if we can get the above to work.  Otherwise the message would be that the session has expired and they must re-enter data.

Thanks,

Jeff

[Bruce]

Hi Jeff,

>> My first choice would be to save the partial data, so the user can go back and pick up where they left off. 

You can do this easily enough.
a) create a routine to do the partial save. This would be something like;
Access:whatever.Open()
Access:whatever.Usefile()
file:guid = p_web.getsessionvalue('file:guid')
If Access:whatever.Fetch(file:guidkey) = Level:Benign
  p_web.SessionQueueToFile(whatever)
  Access:whatever.TryUpdate()
end
Access:whatever.Close()

Then call this routine from the validate::xx routine for each field (xx) where you want to partially save.

>>  Only fields such as GUID and Patient_ID, are saved at expiration.

Given that nothing is saved on expiration, it would suggest these fields are set, and the record created, when the form opens.

>>  The Study_ID which is primed/constructed in the validate Insert embed, is not getting set at expiration.

Expiration happens on the _server_ not the client. (The client can, and often does, have a separate timer, but it's unrelated to the server)

>> I tried priming the Study_ID on the Templates Priming tab (on insert), but it did not work.

I'm sure it did work (ie prime) at that point, but it happened after the record was created, so did not save.

>> A question here is, does the auto-incremented Patient_ID get set upon Insert or only at Save?

depends on your settings (advanced tab) and also your use of auto-numbering (with child procedures, like browses).
It tries to do it at the end, but in your case it's happening at the beginning.

>> I would also like to display a page to the user, if they let the session timer expire. 

there are numerous examples that have this code in the PageFooterTag procedure.


    p_web.Script('startCountDown('& int(p_web.site.SessionExpiryAfterHS/100) &',"' & clip(p_web.site.DefaultPage) & '?logout_btn=logout_btn","countdown");')

this can be coupled with a DIV on the page; something like
<div class="nt-right nt-countdown">Session Expires In:<<div id="countdown"><</div><</div>
to show the countdown to the user.

regardless of whether it is visible or not, the countdown redirects to the second parameter if it gets to 0.

Note this is all client-side code and while it mimics the server-side session ending, it's not actually related to the server-side session ending...

cheers
Bruce

[jking]

Bruce,

     Thanks for the detailed response.  I added the code you suggested to the validate::xx field for Study_ID.  It did not seem to do anything.  Next, I added the code to the validate::xx field Patient_Age.  Now, the Study_ID is saved but the Patient_Age field is not.  Each validate::xx routine has two labeled Start and one labeled Add Server Side Code here.  Which is the one I should be using?

Also, you mentioned ..."nothing is saved on expiration, it would appear these fields are set and the record created, when the form opens."  I do set some fields in PreInsert (Before Primerecord and End).  Is PreInsert run when the form opens?  If so, this is the source of these being set.

Thanks,

Jeff

[Bruce]

>> Which is the one I should be using?

View the embed points "in context" - read the generated code, and make your own deduction...

>> Also, you mentioned ..."nothing is saved on expiration, it would appear these fields are set and the record created, when the form opens." 

>> I do set some fields in PreInsert (Before Primerecord and End). 
>> Is PreInsert run when the form opens?

If the form is in Insert mode, yes.

>>  If so, this is the source of these being set.

I think you are maybe confusing field values with Session values in your understanding.

Cheers
Bruce