[AccessD] FW: Translation DB

John:
 
I just got another great solution from Jim Dettman, which you should take a
look at.  
 
Now I'm thinking that for your eBook - unless you want to stick strictly
with classes and collections - you could take all of these solutions and
include them as a case study in how many great ways there are to skin this
cat.  I think it might make an interesting story if followed chronologically
- how the discussion of translations stimulated al these terrific solutions.

 
I don't know how big the market would be for this, but for anyone interested
it would be of great value.
 

Rocky Smolin

Beach Access Software

858-259-4334

www.e-z-mrp.com <http://www.e-z-mrp.com/> 

www.bchacc.com <http://www.bchacc.com/> 

 

 

 

  _____  

From: Jim Dettman [mailto:jimdettman at verizon.net] 
Sent: Wednesday, February 25, 2009 6:43 AM
To: 'Rocky Smolin at Beach Access Software'
Subject: Translation DB


Rocky,
 
  First let me point out that this is just proof of concept.  I would not
consider this "polished" and ready for production by any means.  For
example, I open the translation table as a global recordset, but don't close
it anywhere at present.   SetLanguage() should be callable from anywhere not
just frmSelectLanguage, so it should be checking that the languageID passed
in is a valid one, etc.  There are a bunch of ways that you could move
forward with something like this,  and that is why I haven't tried to
address any of those issues.
 
 When you open the db, the Language selection form will pop up.  Pick any
one of the languages and then open another form and you'll find it
translated. Note that you must select something or you'll get an error.
Again, it's just not polished off.
 
 For me, hooking this in would be a simple task even though with my Access
apps I typically don't use classes.  For a number of years I've used
standard routines that I call from every forms OnOpen, OnClose, etc. events
and I would simply add this call to one of those routines.    I do have some
extra overhead in that if I need to change the call for the event I have to
run through every form, but I have code to do that so it's quite painless.
In affect, for the most part I get the same thing that John gets with his
classes, but without all the additional overhead of using them.
 
  If your not already doing that, this would probably be a good time to do
so and put the translation in the standard procedure.  ie.  Open event:
=StdFormCtrl([Form],"OnOpen").    The translation would be called in
StdFormCtrl().
 
 I do use classes when I need multiple instances of something, but for the
most part I stick to standard procedures when working with Access since
class implementation in VBA leaves something to be desired (no
implementation inheritance and since inheritance really is the whole point
of using classes, I think they are more or less a waste in Access).
 
 Performance wise I think you will find this more then acceptable.  Of
course, the language translation table would need to be part of the FE.  It
would not be something I would stick a BE since it will only change if the
app changes.
 
 Performance I think should continue to be more then acceptable even if you
added another dozen languages or so.  You could also go back to the
de-normalized approach you had with each language in a separate field in a
single record if it did prove to be a problem.  The only thing this would
change is that you'd need to add an if check on the language ID to get to
the right field.  Although now that I say that, that is not even true as you
could store the language name as well as the ID and reference the field in
the record set by name: grstTranslate(gstrLanguageName) when grabbing the
translation.  With the DB I'm giving you, it would be easy to test as I left
the original table.  You just need to make a few minor modifications
SetLanguage() and TranslateForm()
 
  Note also that I only did label captions.  I didn't touch buttons.
 
Enjoy!
 
JimD.