MS Access for an ASP.NET project

  • Thread starter Thread starter C P
  • Start date Start date
C

C P

I'm designing an ASP.NET custom component, the content of which will be
data-driven. The data that the component will use only needs to be read
only. I had thought about using an XML file for the data source, but I
think the file would be a few MB's. I don't understand XML too well, but my
understanding is that my component would quite likely have to read the whole
XML file even if the info of interest didn't take up the whole file (or at
least I'd have to load much of the file into memory). I'm considering using
an MS Access file instead. Is MSAccess/Jet going to be ok for this sort of
application, since it will be read only? SQL Server could be an option, but
I'd like to keep this stuff in a 'protected' format of some sort where only
I (as the component designer) would have access to it's contents.

Thanks,
Chris.
 
SQL Server would be more secure but I think XML will do it for you. If you
have an XML file, you can use DataSet.ReadXML("FileName.xml") and then you
can reference everythign in DataSet.Table.Column or Row format and you can
use DataTable.Select or DataView.Rowfilter to get specific data. Access
probably isn't the way to go if you are going to have more than a few users,
and since MSDE is free and gives you quite a bit of power, it may be the
better tool. I use XML extensively and if your file is only a few megs, you
can read it and cache the dataset and your performance should be pretty
decent.

HTH,

Bill
 
I'll look into XML some more. I guess I need to figure out how to work
caching. Basically I am building a component that will display a large
number of questions which will be organized in a heirarchy. The idea is
that on any given (web)page there will only be about 10 or so questions, and
the user will have a tree view to navigate through the questions. I'm
hoping to keep this nice and lean. I will be storing the questions' answers
in SQL Server, but the hierchy of questions and possible answers will be in
XML or MSAccess or something. My thinking is that with the tree view the
user can quickly jump to any 10 questions they want, and my pages can be
kept small. I am also hoping not to have to maintain much session info
between postbacks. Maybe I can explain better with a use case:

- User goes to a webpage for a form which will display the 10 default
initial questions
- User answers the questions
- User clicks on a [Next] or [Save] button, or a link in a treeview
- Form of 10 questions posted to the server
- Server saves the user's 10 answers to SQL Server
- Server returns a page of the next 10 questions (matching the link from
the tree view, or [Next] button etc.)
- process repeats until the user doesn't want to answer any more questions

While there may be 1200 possible questions for the user, they'll only be
presented with 10 or so at any given time, so I'm thinking that a model
where the component only has to load the 10 items of interest (and a few
other items needed to construct the treeview) is best. Any caching would
need to be available to several users or at least available from postback to
postback, to be of any value (if I'm going to be loading a whole 3-4MB XML
file in memory). I'm not sure if I'm making sense - ASP.NET is new to me.
But my understanding is that I should avoid having to maintain state, and
avoid loading lots of info with every postback (even if it's not all going
to be displayed). I'm not clear on how I could load in a 3-4 MB XML file
into memory and have it available for multiple sessions.

Thanks,
Chris
 
Hi Bill,

I am in doubt, so I add it to your thread.

I think the advice of the XML dataset is not a good advice. It is an asp.net
project so the XML dataset need to be readed every time when the user pushes
a button or set completly streamed to a viewstate, putted in a session or in
another way in the memory of the server.

I agree about the decission between MSDE and Access, but I am in doubt if
MSDE is limited in the amount of concurent users?

And therefore I let the next answer to you.

:-)

Cor
 
After reading Bill's advice, I did some more searching and found the
Application Cache. It seems my best bet will be to use XML, and load the
XML into my App cache. This way the XML won't be loaded that often, but
will be quickly available (if I understand things correctly).

Just for my own understanding about Access though... I know Access can be a
problem (performance and corruption) if there's a lot of users updating the
file, but if everyone is using it in a read-only manner, shouldn't it be ok
to use Access?

Thanks,
Chris
 
Hi Chris,

I find this a greath idea, I have myself to study for the aplication cache.
However if you can reach it from all your visitor pages, this sounds as a
greath idea.

Maybe it is even better if you first look to the static/shared classes in a
webform. They belongs also to the application and not to the session, but
that is also something I have to get to know myself how I can reach them
from all the sessions, so I cannot help you and also not say if it will
work.

And if that does not works, than you still can look to remoting (a pipeline
between two programs).

If you get this working, than is this in my idea an approach that gives you
performances you even cannot reach with an SQL server.

My expirience is that the startup time from an Access database is terrible
slow even for reading and that is someting your pages have to do a lot of
time.

Cor
 
Back
Top