Prev: Datumveld naar tekst veld.
Next: Library Reference not recognised - comdlg32.ocx - Microsft Common Dialog Control issue
From: Michiel Rapati-Kekkonen on 3 Apr 2010 14:52
"Roger" <lesperancer(a)natpro.com> wrote in message
On Dec 14, 12:38 am, "Tony Toews [MVP]" <tto...(a)telusplanet.net>
>> "Tony Toews [MVP]" <tto...(a)telusplanet.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
> table with all the unique label text once. For example "Customer". Have
> 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
> 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
> tables. And do form/report lookups on that single table.
> Maybe. Try it on a slow system and see what you think.
>> 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!
--- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---