multilingual application

#11

"Roger" <lesperancer (AT) natpro (DOT) com> wrote

On Dec 14, 12:38 am, "Tony Toews [MVP]" <tto... (AT) telusplanet (DOT) net>
wrote:

Quote:

"Tony Toews [MVP]" <tto... (AT) telusplanet (DOT) net> wrote:

Now a key performance tip is to arrange and read the data from the
table/query in to
fill your form report controls with one index read. That is if you have
30 controls
and labels on your form don't do 30 different recordset index "seeks'
into the
table/query. Intsead arrange your data so that you do one index "seek"
and then read
all the thirty records belonging to your 30 controls one after the
other. Now these
don't have to be alphabetical sequence or anything like that. After all
it's very
fast changing the control and label caption. But it's relatively slow
reading the
data from the tables for each form and report open.

Just to follow up on this one. You might want to go so far as to have a
normalized
table with all the unique label text once. For example "Customer". Have
the
translation table for that label.

Now you programmatically read all the forms and reports willing in tables
with all
the occurances of the various strings. So you probably have at least three
tables.
Form/Report name, caption table and junction table with foreign keys
pointing to the
two just mentioned table.

(There's also a message table too but we'll ignore that for now.)

To get the maximum performance when opening a complex form with lots of
controls you
might want to create a totally denormalized, indexed table from the above
three
tables. And do form/report lookups on that single table.

Maybe. Try it on a slow system and see what you think.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages -http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog -http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated seehttp://www.autofeupdater.com/
Granite Fleet Managerhttp://www.granitefleet.com/

or you could set up the tables as outlined by Tony
and do the processing once, per language, creating one FE per language
so that users don't have to pay a performance penalty while you
translate the application

And that is how I have now done it, indeed.
It now takes two minutes to personalize the application:
messages, labels all translated and the specific options in place.

Thanks all for your very sound advice!

Michiel

--- news://freenews.netfront.net/ - complaints: news (AT) netfront (DOT) net ---

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

multilingual application

comp.databases.ms-access comp.databases.ms-access

Re: multilingual application - 04-03-2010 , 01:52 PM