I have a web form which displays and updates a record. This works fine, when the save button is pressed and the changes are committed to the database and the page does a Response.Redirect onto itself with a success message across the top. The problem is when the page reloads, it is displaying the record as it was prior to the UPDATE. Refreshing the page (F5) displays the changes to the record as they should be.

When I debug the form and step through the code, it behaves properly - I can see the updates to the record in quick watch and when the page reloads, all is as it should be. This is even the case when running in debug but not stepping through it. It is only when running the app normally.

Anyone have any ideas? Its as if the database content or the SELECT query is being cached. Or, there is a delay in the saving of the MDB of a few milliseconds or so (enough for the the page to reload and get the old data). I've never had this problem while using SQL Server. Should I alter my connection string?

Are you using a MasterPage or Base Form for your aspx pages? For one, you don't need to place your no cache code in multiple places. Are you working with an IE Browser? Mozilla? Opera? The Response Headers will be evaluated differently depending on browser, but this code should work in all three mentioned above:

This would go in the Page Load event of your Master Page or Base Page in a best case scenerio - - or in each page if you aren't using any sort of inheritence or static source.

If you are still having problems may I ask what code you have in the page load event? Are you TRYING to cache data? Meaning you have a scenerio when the data should be cached? Are you using an DataSource object such as the ObjectDataSource, I assume you wouldn't be using the SQLDataSource object for MS Access. These data controls have built in Caching properties but you need to set these values, by default data will not be caching by default. If you aren't using a DataSource object how are you binding the datasource? And what is the binding control? (DataGridView, repeater, etc.)

And why are you are doing a Response.Redirect back to yourself. Do you want a full round trip back to the server and a re-evaluation of the headers at this point? Or would a Server.Transfer better match what you need to do here?

Regarding a potential delay from the MS Access database, I'm not convinced that would be the issue, though I also haven't worked with MS Access in ages, especially within a Web environment. However, let me go back to another point raised: are you saying that this EXACT situation with the ONLY change being using SQL Server DOES NOT cause this problem? I don't mean in the past you written applications that use SQL Server with success but using this exact situation, simplying swapping data sources and providers works fine?

__________________
"Artificial Intelligence is no match for natural stupidity." ~unknown

Ok, I have just imported the access database into SQL Server and performed the same operation. This time, it performs as expected with no caching effects. I used SQLOLEDB as the dataprovider as I didn't want to rewrite all my data access layer.

My app is broken into 2 assemblies:
A library which has a DAL layer to interact with the database and a public BLL layer which exposes functionality to...
The web application contains web forms and UI logic.

A web form in the app updates data and then reloads and should display the update. A datatable is returned from the DAL class to the BLL class and then to the calling web form. This datatable is then bound to a gridview. Depending on the status of a row in the gridview, it is highlighted in the gridview's RowDataBound event.

1) If I understand you correctly, you are seeing this unwanted caching behavior will occur ONLY if you change the underlying database to be MS Access, SQL Server doesn't do the same thing.

Interesting. If I had to guess, MS Access is basically a flat file. When you query MS Access you are basically reading that file into memory. Unlike SQL Server which conducts transaction isolation or basically returns back a virtual page set or leaf of data, you are aren't dealing with the actual mdf or page level data.

1) You have tried turning off caching using the methods provided in previous posts correct? And this doesn't help?

MS Access might be experiencing a delay, or for example, if you waited an additional 5 seconds, maybe you would get the proper data back. A good way to test this is to add a last update column to your table. When the data refreshes verify you are actually working with an updated view. if the Last Update date = the date you stored in the viewstate or however you track the loads, you know there is something wrong with how MS Access is returning the updates.

__________________
"Artificial Intelligence is no match for natural stupidity." ~unknown

As an experiment, I set the wait to 10 secs. I had the web form open in my browser and the database open in access. I pressed the Save button and then, very quickly, alt-tabbed to access and opened the table to see if the field for the record had changed. It hadn't. It was only if there was a gap of a second or so between pressing Save and opening the table when the data would show the change made to it be the web form. Really weird. The delay definately seems to be in the update of the database/saving of the mdb.

I suspected it was something like that. What you might want to do is create some sort of wait page or briefly display some indicator that says "refreshing please wait" but considering it is only a second or two, that might not really help the end user experience but make it more annoying .

Since I really never work with MS Access I'm not sure of any good way to fix this. I think what is going on is that the Web Site makes a request through its provider and the MS Access file is cache in memory, since that is the nature of the object, it is a flat file. Since the ASP Identity account needs to load the file into memory, run the update and then release the cache you are seeing a second or two delay.

Are you using .Net 2.0? Have you tried using an AccessDataSource object? ASP.net has provided a data source object specific for working with MS Access, this might help the situation.

__________________
"Artificial Intelligence is no match for natural stupidity." ~unknown

Are you using .Net 2.0? Have you tried using an AccessDataSource object? ASP.net has provided a data source object specific for working with MS Access, this might help the situation.

Can the AccessDataSource object encapsulate my existing BLL functions? And if so, would its caching (or anti-caching?) capabilities have an affect as it is not in direct contact with the database? I obviously cannot through my library away...

I don't know what your BLL does. I was suggesting the AccessDataSource as an alternative method for binding your controls which might natively (since it was designed for MS Access) fix this problem.

At the end of the day the latency between MS Access, the web tier and your BLL appears to be a problem. I was suggesting if the problem is 100% a timing/update issue between MS Access - "how it gets to the web tier" - and the Web Tier maybe the native MS Access Data source object will fix the issue.

I haven't used the AccessDataSource object before since I don't use Access. I'm sure its very similar to the Object and SQLDataSource objects. At the end of the day, none of these .Net controls cache data by default - - I think we have determined the problem is NOT an implied cache being forced by the data controls, but the latency between updates and displaying them in the web tier. The only "non-configured, yet still might cache" component in the equation is the browser, and we have discussed some cache control mechanisms for that in previous posts.

You might want to test, a simple application using the AccessDataSource object and a web page - - see if you can reproduce the problem, etc.

__________________
"Artificial Intelligence is no match for natural stupidity." ~unknown