[AccessD] A Question of Timing

I do this stuff all the time.  It is lightning fast once the collection is
loaded.  The load can take a second or two if there are thousands of
records, but if you do it as the app opens it is generally un-noticable.  As
for test, yea I have a "refresh" button that I use to empty the collection
and reload.  Once an app is stable this method really is an order of
magnitude (or more) faster than any table accesses.  Collections access at
the speed of main memory.  Recordsets may get cached somewhere out there,
but there is no way to ensure that and if they aren't then you will see the
difference.

Grabbing a caption out of a collection will happen at probably tens of
thousands per second so a whole form with even 200 labels (not gonna happen)
would take a couple of milliseconds to load (using a collection as the
cache).  Believe me, it will be completely unnoticeable.

John W. Colby
Colby Consulting
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman
Sent: Thursday, January 04, 2007 3:27 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] A Question of Timing

<<Any particular reason, Jim?>>

  When there might be literally thousands of phrases, that's not something
that I'd want to load into memory.  I've always leaned towards a table
rather then loading something up in memory as I'd rather let Access/JET get
memory for database operations. And I've found seek fast enough (especially
if it's in the local database) for anything I've ever tried.

  Also the use of a collection means you load the whole thing and take the
hit even though you might not need it all.  Modifying/testing would also be
a bit of a chore because as you modified (add/delete/change), you'd need to
load up the whole thing each time.

  This would be a tough call though because the needed functionality is so
integral to the app.  Since it's used everywhere, you'd want it as fast as
possible.  I have to say though that in general, every app I've seen with
translation has always been done with tables.  

  I'd do a lot of testing<g>.

Jim.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Michael R Mattys
Sent: Thursday, January 04, 2007 2:28 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] A Question of Timing

From: "Jim Dettman" <jimdettman at verizon.net>
To: "'Access Developers discussion and problem solving'" 
<accessd at databaseadvisors.com>
Sent: Thursday, January 04, 2007 11:36 AM
Subject: Re: [AccessD] A Question of Timing


> I'd follow gustav's advice and use seek.  I also wanted to add that 
> you can use seek on a remote teable, but you must open the remote 
> database first.
> See code below.
>
> Jim.
----------------------------------------------------------------------------
-
> Also, If you ship this thing with a table with all languages, you 
> could look up a "language" flag as the FE opens, run a query that 
> pulls only records for that language out into the recordset, then 
> store all those phrases in the collection.  In essence, the correct 
> language loads into a collection as the form opens, and then is 
> available as required from that point on.  I call this caching since 
> that is really what it is.  Collections are orders of magnitude faster 
> than tables for this kind of thing, and their performance won't 
> decline as the number of users in the db grows.

> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com


Hmm. Now I'm curious. The 'orders of magnitude' wasn't spoken against and
yet Jim still went with seek. Any particular reason, Jim?

Michael R. Mattys
MapPoint & Access Dev
www.mattysconsulting.com 

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com