We Keep Coding

ASP.Net C# Web Form: Prevent new server session while previous is processing

I have an ASP.NET 4.5 web form running C# code behind on a server. A specific form often takes some time to finish while it updates and changes various database records. However, if the user closes the tab or tries to reopen the web form, it will try to check the users status in the database and fail when those later change due to the first running process.
The need is to track this specific instance of the process and user, and if it is still running, prevent the page from loading fully or redirect. I was hoping to find and store some user and process information on a cookie and then simply check for this each time on page_load. I was not able to find these variables/properties.
Am I going about this the right way, and if so, how can I accomplish this?
Thanks!

I was not able to find the exact solution I was looking for. At the moment, I cannot see any way to find a server side identification id of the process.
Instead, I referenced How to tell if a page unload in ASP is a PostBack and made it so that the page would warn when being unloaded before the confirmation screen is shown. As long as the form opens to the same named tab, the user would be given the warning screen and given a confirmation before they could close or reload a new web form instance.

What Internet Explorer settings might affect SQL queries functioning differently?

Vague title, but it's tricky to word well in one question.
I have a site which uses a local database to store reviews, and in another table we store ratings of those reviews, so every time someone clicks a thumbs up / thumbs down icon next to a review a new entry is added to that table, much like the "is this review helpful?" feature you see on many sites.
This is done using a js function which triggered when either thumb is clicked on, which then calls an aspx page and in the C# behind we check if the user has already voted on that review, and if so to update the database appropriately (e.g. removing their vote if they have already voted in that direction).
This works well in Chrome and IE on the laptop I am working on. I have tried the latest IE 10 standards as well as IE 8 standards as the latter is what most people will be seeing the site with, but it partly doesn't work on someone else's computer with the same browser version installed and same standards set. I had this user log in to the site on my machine to see if it was a user account issue, but it worked fine for them on my machine.
I have tried loading the site in InPrivate browsing windows to prevent any caching affecting the issue.
It works for them to submit a vote, either up or down, and they can change their vote from up to down, and the database is updated correctly. If they try to remove their vote however, it simply doesn't work.
It's not a user issue, as it works fine for both of us on my machine, and for neither of us on their machine, so I figure it some browser setting of some kind.
Summary:
- Works in Chrome
- Works fully in IE on one computer
- Doesn't work fully in same IE on another computer
Any pointers?

Caching issue. This explains why the database was updated the first time, but each time after it wouldn't work properly. Using the code below to prevent caching:
// Stop Caching in IE
Response.Cache.SetCacheability(System.Web.HttpCacheability.NoCache);
// Stop Caching in Firefox
Response.Cache.SetNoStore();

c# cache not persisting between users

I'm experiencing some problems with the use of System.Web.Caching.Cache.
Basically I'm using
Cache.Insert(tablename, newlist, null,
System.Web.Caching.Cache.NoAbsoluteExpiration,
System.Web.Caching.Cache.NoSlidingExpiration);
to insert objects into the cache, and Cache[tablename] to retrieve them on a webform.
What I'm experiencing is that if I refresh the browser that calls these methods, then the data is there, and Cache.Count reflects this.
However, if I close the browser and start it up again, or start a different browser on my test machine or another, then the Cached data is not there.
Ie the Cache is working as if I was using the Session Store. I've also tried using the Application store too, but with exactly the same results.
I've had a look through my application pool settings and web.config, and can't see anything obvious.
Any help with this would be much appreciated, as requerying the databases to get the information to put in the cache would slow down the webform a great deal.
I'm not sure I'm being clear enough.
To reproduce.
browser 1 opens webpage, no cached data
browser 1 refreshes webpage, cached data
browser 2 opens webpage, no cached data
browser 2 refreshes webpage, cached data
browser 1 refreshes webpage, cached data
So as you can see, it's working exactly as if it was session only data, not a common cache. Using the callback probably wouldn't tell me anything, as the data is still there, just not available to a fresh session

Sounds like you restart the application by pressing F5 in Visual Studio.
Just open a new browser Window without restarting the application.

Controlling browser forward/back functions in web application

I'm writing a web-based application for internal use within the business where I work. It's a fairly complex application, with a lot of forms that will allow the user to view and enter data, which once saved will be stored in a database.
One thing I'm anxious to avoid is allowing a situation to exist where a user might enter large amounts of data in the browser, and then (either deliberately or inadvertently) navigate off the page without saving the changes. To this end, I have already implemented an entry page which opens up a new browser window in which there are no navigation controls at all; only what is provided on the web pages themselves.
However, there are two potential ways in which a user could still lose data:
The browser Close button is still enabled, and a user could potentially lose work by clicking it inadvertently. I can probably live with this, as it falls at the extreme end of helping the user not to shoot himself in the foot.
In Internet Explorer (and, apparently, in Firefox) the Backspace button works like a Back button. I only discovered this accidentally, and have as yet been unable to find a simple way of stopping this behaviour. This is potentially a problem, as an inadvertent use of the Delete key (e.g. having positioned the cursor in a read-only textbox, or when the cursor isn't on any particular field in the page) will navigate off the page.
What I would like to do, as a minimum, is prevent Backspace from navigating off a page if that page has any user-writable fields on it and any of those fields have been changed by the user since the form was loaded. Ideally, I would like to disable this particular use of the Backspace key completely, while the user is logged into this web application. The two possible ways that I can think of, for achieving this, are: (1) clear the browser's history as each page is loaded, or (2) trap the Backspace key and only allow it to work if the cursor is positioned within a field whose text can be changed (e.g. a textbox).
Can anyone suggest how I could achieve either of these things? The solution needs to be programmatic, rather than something that has to be manually configured on every browser in the company.

Instead of blocking* functionality that your users have learned to expect in their daily activities at work and at home, why not work with it? Make the "back" button actually take them to the previous screen as expected, and use AJAX to silently save the form as they fill it out (say, every 5 or 10 seconds), so when they return to the form you can check to see if they already have partial, unsubmitted values saved and reload them.
This approach aligns with the realities of web-based applications and delights users if implemented well. An alert that says "you did something wrong" just frustrates users and makes them trust your application less. Remember - users almost never do the wrong thing. It's our applications that aren't aligned with usage.
* more like trying to block functionality. As you've discovered, people who designed the interwebs and web browsers never really intended for site developers to totally disable moving back and forward in the navigation history.

What about something like this? You can ask them if they are sure before they leave.
var changes = false;
window.onbeforeunload =
function()
{
if (changes)
{
var message = "Are you sure you want to navigate away from this page?\n\nYou still have unsaved changes.\n\nPress OK to continue or Cancel to stay on the current page.";
if (confirm(message)) return true;
else return false;
}
}

You should look at the Javascript's window.unload event.
This is fired when the use tries to leave the page. You can't totally stop them leaving the page, but you can give them a chance to cancel.

try this
window.onbeforeunload() {
return "Are you sure you want to navigate away?";
}

How do i lock an asp.net page from multi-user editing?

i have a page with a series of checkboxes that authenticated users can change. I need to make this page only editable by one person at a time. So if a user goes into it and edits one of the checkboxes, noone else can go into the page and change other checkboxes.
I thought about an edit page link and a readonly page link (all controls disabled), then set a database flag if user enters under edit mode, but my concern is i wouldn't know if the user changed something, then just x'd out of the browser/app, locking everyone else out.
This is an internal app to company. Has anybody done something like this?
Any ideas or thoughts or suggestions?
Thanks

We have this functionality on an older ASP app. The user will load data with some type of primary key. We put in a DB entry to "lock" that page. If they correctly move through the site, it will unlock the resources at that time.
Other users opening this page will receive indication that the page is locked and a read-only version is rendered.
It would be fairly trivial to code a unPageUnload AJAX call to reset the lock for browser closing. We don't find this to be much of an issue and old locks are just cleared by an evening process if more than 4 hours old.
Our situation is where the pages are tied to specific regions of data. If this is a general config screen, I think a more dynamic AJAX solution that pushed the updates back and pings for changes might make sense. You would have to decide if you want to disable changes from others after the first update is received or implement collision detection for the data.
Some type of hashing of the page data would probably make this easier to detect changes.

You do what you said, but add a client side timer which will ping the server and tell you they are still there. If you don't get a ping within x mins you could let a new user go into edit mode but perhaps warn them (or not).

What about letting all users edit this page and how your script check in for page updates? Just like SO does, while you are typing in an answer, an orange message appears above saying "At least one new answer has been posted". You could display something like "The page has been modified since you last opened it".
There was something like timer in ASP.NET AJAX. You could use that to talk to the server to send "IN EDIT" status updates. You can even go further. Say you send "LOCKOUT REQUEST" requests every 15 seconds asynchronously and you expect to receive the "LOCKOUT GRANTED" response from server. If the response hasn't been received, you disable all controls on the page until maybe the next request receives the confirmation (the previous message could have been lost in the network). This way, if one user closes the browser, the other won't have to wait many minutes or hours until they get the edit permission.
Essentially, you need a distributed implementation for a critical section concept. It maube a challenge to implement it over HTTP. But that's a very interesting challenge, isn't it?

If you're trying to prevent two users from updating a db record and over-writing each other, perhaps it would be easier to detect this than prevent it.
On strategy for this is to include a "version" field in the record, and save that in a hidden field when rendering the page.
Then you simply include that as a condition of your update (i.e. UPDATE ... WHERE ID = myID AND VERSION = myversion) - if your update returns 0 rows, you know that someone else modified the data, and you can then decide what to do - reload the new data, offer the user a chance to compare them, etc.

How about an alternative to an extended lock?
Since you appear to be manipulating relatively small amounts of data, it would be more polite to put an encoded version of original state of the data in a hidden form field (or a datestamp, though that's less reliable; a hash of the values would work for larger amounts of data). In a transaction, check the state of the database against the hidden form values; if the original record has changed since the user submitted the changes, you reject the update. If not, accept the update, and commit the transacation.

Another approach could be to have an Application variable that contained a map or dictionary of locked items.
So, when one user hits edit, add an entry to the AppVariable Map or Dictionary, with the Key set to the primary ID of the field being edited. Then for all further requests, when they change between records, do a check of the ID within the map and if its being edited, Toggle off any update buttons. If you want to do it AJAXy, add a timer and an UpdatePanel and poll to see when the lock is released, then refresh the page with the updated data and enable the update buttons again.
Or, as a slightly greater UI, allow the users to edit while waiting for the lock to release ( the Map item to be removed ), then when it is removed, compare the fields they have been working on, with the updated database values and allow them to overwrite/merge their changes.
The only real downside is, 1) You would need to create one Application level Dictionary or Map for each table that you want to lock/unlock. 2) If you get into a webfarm environment, it breaks and you would have to use a different system.
Does that make sense?