Re: In Memory problem

[pbl...@odstrategies.org]

What I do for tables that really don't change much is to make an alias
memory table but make it a real table not an alias of the disk file
and don't use any IMDD templates at all. You can copy and paste the
disk table then change the driver to memory. I also make it a threaded
table too.

In the DCT I add triggers to the AFTER add, change, and delete to
update the real disk table by adding the real ABC commands to the
memory table triggers to manually update the disk table. I use after
triggers so if there is a problem it won't mess up the disk file.
After triggers won't fire if the operation fails on the memory table
add, change, or delete.

I write a process to manually load the memory table it at program
start. You can use the After CODE statement global embed as a place to
do that since it's the very first code executed. Once loaded you can
forget about the disk table. Populate all the templates that need
access using your memory table version adding any relationships
required for maximum use. You now forget about the disk file and never
use it again.

Now when you use hand code you work with the memory table using ONLY
ABC code and pretend it's the real one. The triggers are done for you
by ABC and you can just do whatever you like with the memory table and
all changes are reflected back to disk. If you find you need to change
the table a lot or it gets too large then you probably should not be
using a memory table.

I find the cache template can be fine for mostly static tables but if
they need to be managed in hand code the templates are hard to use. If
you need all this to be multi user then you need to subclass
FileManager and roll up your sleeves.

On 30 Dec 2009 01:38:49 -0500, "Jari Bergstr�m" <ja...@softmade.fi>
wrote:

>The problem is that I am using aliastable which is cached.
>If I cached the orginal table it works fine.
---------------------------------------
Paul Blais - Hayes, Virginia