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 news:d38b6057-6710-497b-a4bc-7552527ef4f5(a)33g2000vbe.googlegroups.com... On Dec 14, 12:38 am, "Tony Toews [MVP]" <tto...(a)telusplanet.net> wrote: >> "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 >> 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(a)netfront.net --- |