Re: Strange delay behaviour

Jonathan Grant wrote:
> I develop asp applications for a corporate intranet. The users of the
> intranet are divided amongst various trusted domains which each seem
> to use their own proxy server. I have developed an application to
> enable users to book a place at a meeting. This is where everything
> goes base over apex. If I test the application using various domain
> IDs I do not get any problems, however, in the real world I have
> noticed that the db is not being updated immediately, but in chunks
> after a time delay. This is not only causing meetings to be
> overbooked, but also seems to be stopping the count of bookings from
> being updated. I have tried all sorts of code to force no caching,
> record locks, etc and I have noticed that some of the changes don't
> appear to have propogated through to some users, but there doesn't
> appear to be any consistency there, either. Does anybody have a
> suggestion as to where I might look to try to resolve this, I am
> strongly inclined to suspect a proxy issue, but I am not very
> knowledgeable in this area? I have attached my asp page.

What database are you using? If Jet (Access) then you need to consider
switching to a server-based database such as MSDE or SQL Server.

Jet uses a delayed-write process* to improve performance. You can modify
that behavior but you would be better off switching to a more scalable
database.

*see
http://www.google.com/search?sourceid=navclient&ie=UTF-8&rls =GGLD,GGLD:2003-36,GGLD:en&q=Jet+delayed%2Dwrite

HTH,
Bob Barrows
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

Re: Strange delay behaviour

Sorry, I was so concerned about explaining my problem I forgot the basics.
The DB is MS SQL. IIS is running on NT 4!

Re: Strange delay behaviour

Jonathan Grant wrote:
> Sorry, I was so concerned about explaining my problem I forgot the
> basics. The DB is MS SQL. IIS is running on NT 4!

Then there is unlikely to be any delay in writing results.You will need to
look for another cause of your problem.

I obviously cannot run your page to see what the problem is, but a quick
glance does yield some suggestions

For one thing, I would get away from your heavy dependence on recordsets for
updating and switch to using stored procedures to accomplish your updates,
inserts and deletes. In fact, IMO, there is too much data processing
occurring on the page - most of it can and should be moved into stored
procedures. Not only will this reduce the number of calls to the database (a
good thing), but it will also allow you to wrap everything in a transaction,
perhaps alleviating your problem.

I dislike using the self-posting page model for this type of activity - it
makes debugging extremely difficult (IMO). Other people do like it so I
guess it's a matter of style ...

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

Re: Strange delay behaviour

Thanks for the help. I have used stored procedures for other applications
but find it tricky when coming back to the app after a period of time to
pick up on what is going on. I will give it a try, though, but as I
originally mentioned, some changes don't seem to propogate out to some users
so they might carry on with the curent page. I also used to use separate
pages, but again find it easier to follow the logic if it is all in one
page, personally.

I guess I'll have to try some other path to resolve this.

"Bob Barrows [MVP]" wrote in message
news:OugGHoAtFHA.1568@TK2MSFTNGP10.phx.gbl...
> Jonathan Grant wrote:
>> Sorry, I was so concerned about explaining my problem I forgot the
>> basics. The DB is MS SQL. IIS is running on NT 4!
>
> Then there is unlikely to be any delay in writing results.You will need to
> look for another cause of your problem.
>
> I obviously cannot run your page to see what the problem is, but a quick
> glance does yield some suggestions
>
> For one thing, I would get away from your heavy dependence on recordsets
> for updating and switch to using stored procedures to accomplish your
> updates, inserts and deletes. In fact, IMO, there is too much data
> processing occurring on the page - most of it can and should be moved into
> stored procedures. Not only will this reduce the number of calls to the
> database (a good thing), but it will also allow you to wrap everything in
> a transaction, perhaps alleviating your problem.
>
> I dislike using the self-posting page model for this type of activity - it
> makes debugging extremely difficult (IMO). Other people do like it so I
> guess it's a matter of style ...
>
> --
> Microsoft MVP - ASP/ASP.NET
> Please reply to the newsgroup. This email account is my spam trap so I
> don't check it very often. If you must reply off-line, then remove the
> "NO SPAM"
>