Large processing tables

[Walter Vaughan]

Brian K. White wrote:

> <>----- Original Message -----
> From: "Fairlight" <fairlite at fairlite.com>
>
> It defies understanding
> without a reasonable explanation--at least it does for me. Yes, I'm
> likely
> the exception. What else is new? :)
>
>
>Defies understanding? You are that unimaginative?
>
>It's been my guess that all those various static limits and structures (like 
>the flat file format itself) are a large part of what makes fp fast.
>  
>

As I work more with a big iron framework, I've come to appreciate that 
no longer
is "fast" the primary consideration. I can fire an 8 core at it if I 
need more speed.
It's funny to watch mySql vs. PostgreSQL wars break out
and have "it's just a flat file database" curses lobbed over the ramparts.

<more topic drift>
I still believe there is value in some of fpTech's IP. The whole "edit" 
concept should have
fpTechnologies a major sponsor at AJAXWorld. Instead toolkits like dojo 
are filling the need poorly.

The *report mechanism could be forked into a method to create paper reports
from views. Create a GUI that walks you though creating views and then 
builds upon them.
The problem with all the existing SQL report writers is that they expect 
you to work from
a single table and they think in pixel level accuracy rather than any 
kind of text column accuracy.
No one has a snap to text position for elements.
</more>

<even more drift>
What's comical however is those who think a 64 bit OS is faster by 
defintion.
</even>

--
Walter