[AccessD] Find First in an Array?

jwcolby jwcolby at colbyconsulting.com
Sat Feb 21 00:20:01 CST 2009


LOL.  Nothing like a religious war to get the blood pumping.

;)

John W. Colby
www.ColbyConsulting.com


William Hindman wrote:
> ...yikes! ...the JIT tab war ...then the bound/unbound war ...and now you 
> want to start another one?
> ...static data goes in the fe ...the cache has better uses ...imnsho :)
> 
> William
> 
> --------------------------------------------------
> From: "jwcolby" <jwcolby at colbyconsulting.com>
> Sent: Friday, February 20, 2009 4:01 PM
> To: "Access Developers discussion and problem solving" 
> <accessd at databaseadvisors.com>
> Subject: Re: [AccessD] Find First in an Array?
> 
>> Rocky,
>>
>> I was not addressing anything other than the "assumption" that was 
>> expressed that certain tables
>> "would be in the FE".  If you as the owner / developer want them there 
>> that is all that needs to be
>> said.
>>
>> In MY systems I never place such tables in the FE.  If I were to 
>> "purchase" or other be placed in
>> charge of your systems, I would move the tables to the BE.
>>
>> Remember though that I DO cache my "rarely modified / often used" data so 
>> it does not matter that it
>> is on in a BE on the server.  It will cross the wire only once per form 
>> per user.  Thereafter it
>> will almost certainly be as fast or faster than a local FE table.
>>
>> To address your question:
>>
>>> In my case, where the 'data' is really static, and is needed by each 
>>> user, wouldn't the design be
>> better with the language tables in the FE?
>>
>> This is one of those things that is purely opinion, and often near 
>> religious in conviction, and I do
>> not want to start a religious war.  Some people wholeheartedly believe in 
>> placing such things in the
>> FE.  I wholeheartedly believe otherwise.
>>
>> Often a belief is created in the distant past when we make a decision of 
>> some sort that sways the
>> argument in one direction or the other.  We often then stop "thinking" 
>> about it and simply "believe"
>> it.  If enough time passes, we may completely lose track of why we even 
>> believe something.
>>
>> In this case I would guess that those who place such tables in the FE have 
>> either never thought of
>> or considered caching it, or considered and rejected it.  In those cases 
>> having it in the FE solves
>> a speed problem.  Now these people have "solved" their speed problem and 
>> the "reason" fades into a
>> belief.
>>
>> I started using data caches some time ago and, while I never used data 
>> tables in the FE even before
>> that, having the cache simply makes the FE Data Tables concept a 
>> non-starter.  In all other respects
>> (IMHO) having data in a BE is the accepted practice.  Since my caches 
>> solve my speed issues I truly
>> do not need them in the FE.
>>
>> John W. Colby
>> www.ColbyConsulting.com
>>
>>
>> Rocky Smolin at Beach Access Software wrote:
>>> " I am not going to get into the "this is a local table so it goes in the
>>> FE... oh damn, now I gotta go update the data in 5 different FEs".  BEs 
>>> are
>>> for data (in my world)."
>>>
>>> In my case, where the 'data' is really static, and is needed by each 
>>> user,
>>> wouldn't the design be better with the language tables in the FE?
>>>
>>>
>>> Rocky Smolin
>>> Beach Access Software
>>> 858-259-4334
>>> www.e-z-mrp.com
>>> www.bchacc.com
>> -- 
>> AccessD mailing list
>> AccessD at databaseadvisors.com
>> http://databaseadvisors.com/mailman/listinfo/accessd
>> Website: http://www.databaseadvisors.com
>>
> 



More information about the AccessD mailing list