Asp.net caching vs Access Caching.

[olle]

Hi folks.
I learning asp.net and compare it with traditional asp and
Access-developing.

The issue is this one:
1/I have this Ms Acceess adp-project application that works fine on my
Ms Sql server database.
In my main form I have an Access-combobox with Customer-names from my
customer table.
In this combo-box are about 2000 records.
With this combobox the users can make a database query to work on only
the records in
my main table that are related to the customer they have chosen.
In this situation the comboxbox load very quickly.

2/ Then I moved the sql server databases to a remote server.
Then I connect though my Client Access2000-adp file through internet.
Now the combobox with customer names loads more slowly, but only then
first time when I load the Access main-form.
Then it seems that the combobox is cached somehow because then the
users can look for customer-records fast and convient.
Also this approch is OK for my users.

3/ And now I try the same approach with an asp.net-webform.
I cach the datsource for the asp.net dropdown. But even so, in this
case the customers asp:dropdown loads slowly on every postback I make.
I think now that my users used to my userfriendly Access-forms wouln't
like the move from the Access app. into an asp.net app.

Thinking about if there is a possibilty to cach comboboxes and
dropdowns on the client the way Access-projekt-asp-forms can do with
Visual studio dot net.
Does anyone know about these issues?
BigOlle

[Bob Alston]

ol**@ylm.se wrote:

Hi folks.
I learning asp.net and compare it with traditional asp and
Access-developing.

The issue is this one:
1/I have this Ms Acceess adp-project application that works fine on my
Ms Sql server database.
In my main form I have an Access-combobox with Customer-names from my
customer table.
In this combo-box are about 2000 records.
With this combobox the users can make a database query to work on only
the records in
my main table that are related to the customer they have chosen.
In this situation the comboxbox load very quickly.

2/ Then I moved the sql server databases to a remote server.
Then I connect though my Client Access2000-adp file through internet.
Now the combobox with customer names loads more slowly, but only then
first time when I load the Access main-form.
Then it seems that the combobox is cached somehow because then the
users can look for customer-records fast and convient.
Also this approch is OK for my users.

3/ And now I try the same approach with an asp.net-webform.
I cach the datsource for the asp.net dropdown. But even so, in this
case the customers asp:dropdown loads slowly on every postback I make.
I think now that my users used to my userfriendly Access-forms wouln't
like the move from the Access app. into an asp.net app.

Thinking about if there is a possibilty to cach comboboxes and
dropdowns on the client the way Access-projekt-asp-forms can do with
Visual studio dot net.
Does anyone know about these issues?
BigOlle

I am also an Access person who is learning ASP.NET
I recommend you get a book: "Microsoft asp.net web matrix starter kit".
I bought it for the info on the FREE Microsoft development environment
Web Matrix (a sort of Lite version of Visual studio . NET). IT also has
good info on caching records read to solve just the kind of issue you have.

I got my copy for about $8 including shipping through Amazon, from one
of their 3rd party vendors.

Bob

[olle]

thanks for your tip.
I problably by this book, if you think that it is userful even if I am
installing Visual Studio dot net instead of webb Matrix.

a question: As I plan to install visual studio dot net on my computer i
wonder if Webb Mattrix can be installed on the same computer.

But I still don't mind getting some more code tip on this issue on
caching asp.net dropdowns on the client

[billmiami2]

ASP.NET comes with all kinds of caching options You can cache entire
user controls or simple objects like datasets. You can also use the
session and application objects to store objects. However, objects
don't get cached by themselves--you have to specify the caching.

The new .NET framework includes the ability to detect when the
underlying data has been changed so that the cached data is always kept
in sych.

Any beginning ASP.NET book will cover the large number of caching
options available.

Bill E.
Hollywood, FL

[olle]

Well bill.
Have looked about caching in :
Mircosoft.net: Deposito: "Building web solutions with asp.net and
ado.net"
and
Sams: Chris Payne: "Teach yourself ASP.NET in 21 days"
and I haven't found anything about caching dropsdowns on the client in
theese books.
Only how you cashe the datasource for the dropdown.
Maybee you know about some good books on this issue?

[olle]

Well bill.
Have looked about caching in :
Mircosoft.net: Deposito: "Building web solutions with asp.net and
ado.net"
and
Sams: Chris Payne: "Teach yourself ASP.NET in 21 days"
and I haven't found anything about caching dropsdowns on the client in
theese books.
Only how you cashe the datasource for the dropdown.
Maybee you know about some good books on this issue?

[billmiami2]

Caching on the client wouldn't make much sense because your client is
the browser. You'll need to take care of caching on the server, which
will benefit all users simultaneously.

In my apps, I use a user control for all dropdowns and I built into it
the ability to cache the source dataset automatically as well as store
the selected value in a session variable. If I wanted to, I could also
store the entire control in cache.

Either of these methods (caching the source dataset or caching the user
control) would work fine for you.

Bill

ol**@ylm.se wrote:

Well bill.
Have looked about caching in :
Mircosoft.net: Deposito: "Building web solutions with asp.net and
ado.net"
and
Sams: Chris Payne: "Teach yourself ASP.NET in 21 days"
and I haven't found anything about caching dropsdowns on the client in theese books.
Only how you cashe the datasource for the dropdown.
Maybee you know about some good books on this issue?

[olle]

Hi again Bill.
bi********@netscape.net wrote:

In my apps, I use a user control for all dropdowns and I built into it the ability to cache the source dataset automatically as well as store the selected value in a session variable. If I wanted to, I could also store the entire control in cache.
Either of these methods (caching the source dataset or caching the user control) would work fine for you. hm.. As cashing the dropdown datasource with 2000 records is too slow I
am thinking of cashing the user control,( Id = "mydropdown-contol"...)
Is this the way to do it:
1/Make a page with the drowdown-control with an outputcache on the
whole page.
2/ Save this file with the name:
"mydropdown.ascx"
3/ Then I use this contol in another page, called for exampel,
"MyUpdateForm.aspx" , where the whole database is updated and ...

Is this approach the way you do it?
/Regards Big Olle
Bill

[billmiami2]

Caching a dataset with 2000 records would be lightning fast. What
makes you think that it would be slow?

I always cache the dataset. I make it part of the way the control
operates. I typically include a boolean property that if set to True
causes the control to cache the dataset and to look in cache for the
dataset when it loads.

I haven't yet had any good reason to cache the entire control.

Bill

[olle]

Hej again.
Here is my tuturial asp.net file.
By default I run a sql-query that returns 16459 Records.
I Cache the whole recordset.
Before i Added the dropdown with 2000 records
this application worked fine.
When I click to get the next record, the dropdown loads slowly every
time even as i have cached it's datasource.
here it is: (hope you understand it how it works even if texts are i
Swedish)
http://databas.ylm.se/olle_test/saml...ing_cache.aspx
/Regards BigOlle

[billmiami2]

BigOlle,

Why are you caching the 16459 records? You should cache the 2000
records that fill the dropdown. The rest can be fetched one at a time

The delay you are experiencing is the time it takes to render the page
on the browser. I checked the size of your page (View Source) and it
was 423 kb or almost 0.5 Meg. Your viewstate was 160 kb of the 423.
This is all caused by having a large dropdown on the form. Note that
if you keep the view state enabled for the listbox (dropdown), ASP.NET
will put the entire list into viewstate, which is taking up most all of
the 160 kb. I would recommend eliminating the listbox if you can or
using a textbox to partially filter the listings in the box. Because I
don't understand Swedish, I don't understand what the listbox is doing,
so I can't give you any more constructive comments.

Bill

[olle]

Well
I cash the records I work on in this test-application in order to find
out how asp.net works.
I cashed a query on 16459 records(..where mymemofield like '%a%'...)
only to see if asp.net can handle moving from record to record in a
recordset like this on. And it does really.
It works fine apart from the case where I added this dropdown on the
page.
In traditional asp you had to query the database on every movenext step
you make.

I am try what happens if you put a listbox with lots of records on a
asp-net page only to find out how asp.net is handling this situation.
In my Access2000.adp I have this listbox to give users the possibility
to chose which records they want to work with.
For example customers from Canada, or Alabama what ever...
As I mentioned I use a Access2000-combobox i the real application and
it works fine.
And it works perfekt also when this Access2000-adp is connected to a ms
sql server database on a remote server.
But it doesn't work on asp.net-pages.

My conclusion is :
There are advantages with developing with Access and in certain ways
asp.net is better.

[billmiami2]

This isn't so much a comparison between ASP.NET and Access as much as a
comparison between a fat client/server application (Access) and a web
application, which is naturally very thin client. A client server app
made with Access, VB6, .NET windows forms or many other platforms can
handle a great many tasks and can do a large part of the processing if
you want it to. In contrast, the browser does almost no work for you
except to paint pictures on the screen. It will cache images and a few
other things but not lists or other elements. Instead, it has to
retrieve them on each postback. There are a few ways to get around
this (frames, iframes, remote scripting, activeX, applets, heavy use of
javascript) where the client can be made to do more work or postback
for only part of the form. Unfortunately, using some of these
techniques can result in a very clumsy app if one is not careful.

If you must load very long lists into the browser, you should do it for
intranet applications where the connection speed is very high.
Otherwise you need to keep your pages as small as possible and make
adjustments as necessary.

There are times when a web application is the best choice and there are
times when a client/server application is best. For example, unless
you use terminal services, you can't run MS Access over a 56k phone
line (or even a T1 without slowing to a crawl) but you can almost
certanly run a snappy web application. On the other hand, you wouldn't
want to dry to do graphic design on a web application.

Bill

[olle]

Thanks for these interesting words.
I am thinking a lot about when to use client/server and when to use
web-based applications.

To use Access2000 project-adp-file to a remote ms server server, using
stored procedures for updates is a really good choiche for working on
databases throught the internet.
I think that if you work on uppdating remote databases you don't use a
slow modem.

But the bad thing with Access it that there are different versions.
Users might have Access95,97,2003 in different windows versions on
there PC:s.
And sometimes they want to work with different versions of Access on
the same computer.

And it is hard to make the Access-runtime to work properly if I am not
there myself
to install it.

Problaby VB is better in terms of deploying your application to many
clients.

I am looking forward to trying VB for the dot.net
/Regards BigOlle

[billmiami2]

The only advantage to using a web application in your case would be in
deployment. If you are making frequent changes to the application and
you have hundreds of users connecting remotely with no direct control
on their workstations then you have an installation/maintenance
nightmare. I would go with a web application no questions asked. The
long list problem can be easily overcome with a few techniques. On the
other hand, if you only have a few users and changes are very
infrequent, then the ADP would be fine.

Bill

ol**@ylm.se wrote:

Thanks for these interesting words.
I am thinking a lot about when to use client/server and when to use
web-based applications.

To use Access2000 project-adp-file to a remote ms server server, using stored procedures for updates is a really good choiche for working on
databases throught the internet.
I think that if you work on uppdating remote databases you don't use a slow modem.

But the bad thing with Access it that there are different versions.
Users might have Access95,97,2003 in different windows versions on
there PC:s.
And sometimes they want to work with different versions of Access on
the same computer.

And it is hard to make the Access-runtime to work properly if I am not there myself
to install it.

Problaby VB is better in terms of deploying your application to many
clients.

I am looking forward to trying VB for the dot.net
/Regards BigOlle

[olle]

Thanks again.
I agree to what you say.
With few users the adp works fine.
but as the number of users is growing I am thinking of
webb-applications for the very future.
BigOlle