Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Client-side "database"

Status
Not open for further replies.

jcale4

Programmer
Aug 31, 2004
63
0
0
US
Hello!

I have an ASP app that serves as an Account Management system for sales representatives. I have included a function in the page that acts as "Filters" for the site. The filters are organized by the sales division hierarchy: Regions contain Districts contains Territories contains Accounts. These filters, when applied are stored in cookies that will follow them through the site, so they get a filtered view of all the reports, input pages, etc.. There are only 4 regions, about 15 districts and about 70 territories. So, i have built a system that adjusts the values of the drop downs client side via javascript arrays. This is great, but i am having a hard time at the Account level. There are 4000+ accounts. I would like to somehow store the accounts client-side (which could update on login to keep the accounts updated), then access those when the user adjusts the region -> territory level. Does anyone have any ideas? I initially thought of using XML and javascript to store and access the division hierarchy, thus relieving my web server. Is this a good option?
 
- Also, i have considered using cookies for the accounts, but have read that Cookies are not to be used as "psuedo-databases
 
The easiest way, certainly, is to store server-side what each user should see and only present that. For a given user you can simply load their options into session variables -- arrays, for example -- and refer to them on every page.

If you had to do it on the client -- though I can't imagine why, since you clearly have access to a database -- as long as you don't run out of room, you can certainly store all of that in a cookie. I believe the maximum is 20 cookies per domain/server and 4k per cookie.

But rather than having the user send that info back on every page view, I think you'd be much better off with it on the server.
 
What happens when you change the name of an account, or add a new one ? or delete one? or change its ID (if you're using ID based PK's) - or what if they change their area of responsibility?..

I wouldn't recommend using Cookies as a repository for these type of things... that is abusing their function a little too much.

If you want to do it client side then use XML Data Islands (Mozilla and IE support these, though in slightly different ways), though you still need to load the full dataset each time so as not to run into the issues noted in my first paragraph.

The better way to do this is to use AJAX (Javascript and XMLHTTP) to get the dependent drop down values upon request from the user, and doing the filtering server side using Session variables to store the users selections / or their account settings.

You could even combine this with your current method, where you load the small datasets into local arrays in javascript, created by the server side code, then use XMLHTTP to retrieve the relevant accounts etc.

A smile is worth a thousand kind words. So smile, it's easy! :)
 
Excellent suggestion.. I know nothing about the XMLHTTP object, so I will do some research and try that.

Thanks!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top