Application or Local variable?

[GaryC123]

I have about 200 fields I pull from a db that contain translations (only pull the relevant language). Now I currently do this for every visitor and this occurs on every page, so the visitor can view the site in his own language. I'm undecided whether this is the best situation or should I use an application variable in the global.asa. The problem with this is that this is a distributed application where some people may not be able to use the global.asa. What do people think or does anyone have a better alternative. Suggestions about sessions will be ignored - there could be 100 users on at the same time and more.

http://www.intouchmedialtd.com

 

[mwolf00]

I think that the best solution is to default to the most common language until the user sets it to something else. Once they do that, always default to that choice unless they manually choose another.

Having done that, just send them the page in one language...

Programming today is a race between software engineers striving to build better and bigger idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rick Cook (No, I'm not Rick)

 

[GaryC123]

Ermmm thats what I do. The question is - Can anyone think of a better way of getting/storing this translation array rather than loading the array on every page.
This is an example line that sets the text into their selected language
<td align=right><b><%=tranArray(0, rs(&quot;fieldname&quot)%></b></td><td width=122>

tranArray only contains one language.

http://www.intouchmedialtd.com

 

[Michael42]

You can also create and modify a .ini file using the FileSystemObject (FSO) to store and retrieve common values.

I have found this works well even in high volume environments, i.e. no major perforance hit.

-Michael42

 

[GaryC123]

Hows that different/better from using a database?

http://www.intouchmedialtd.com

 

[Michael42]

>> Hows that different/better from using a database?

1. Less overhead than ODBC based connections.
2. Easy to replicate for common app settings.
Can have a common.ini and appname.ini etc.
3. Database independent.
4. Personal preference in some cases.

I use database tables for this too where the situation calls for it.




Thanks,

Michael42

 

[GaryC123]

1. Don't see how it has less overhead, dealing with 6+ languages hows that make it easier?
2. Very easy to use a db for this, and thats what I do. Also if you then want to change information, as in the case of translations I will need to add new translations, you will need to give the folder write permissions, - and in a distributed application this is an headache
3. Multiple db versions is not a problem since most other parts of the program use the db

http://www.intouchmedialtd.com

 

[Michael42]

GaryC123,

OK

Thanks,

Michael42

 

[hithere]

would that be better than setting a cookie on the client machine? that would avoid extra (unnecessary) server connections, you could set the default language that would be requested based on a value in the cookie, when new translations are available the client can change to a new preference (change the value in the cookie), and if it's destroyed - default to the most common language so the client can reset to their preference. this would bypass the global.asa problem.

I would probably also not check for the language on every page unless there's a specific reason to do so. check on the first page and store it as a local variable. maybe pass from page to page in the url or, if using forms, as a hidden form field.

Are all 200 fields used on every page? is there a way to cut back to just the fields needed on each page? it'd increase the hits on the server but with shorter transactions, is that a bad thing? possibly look at using stored procedures to make up any speed losses?

I'm sorry if you've already covered this ground as I'm still learning but, sometimes going over the obvious is a good place to start. perhaps in your responses, it may spark something for someone as well. looking forward to your responses.

mb

&quot;Where's the Ka-Boom? There's supposed to be an Earth-shattering Ka-Boom!&quot;
Marvin the Martian

 

[GaryC123]

Setting a cookie has no relevance to getting the translation data, unless you're suggesting putting all the translations fields in to a cookie! In which case it's no different than just getting the information from the db. Whether there are 10 fields or 50 fields, I can't see any way of programming the page to know which fields it wants, and the difference between pulling 50 fields and 200 fields is negligible.

Obviously I've gone about this the right way and will stick with what I've got.

http://www.intouchmedialtd.com