| pblais@odstrategies.org 2006-07-10, 9:55 pm |
| Personally, I find that you never need bound fields so I don't use
them. Instead, make your view filter strings on the fly: Construct a
filter string as a CSTRING on the fly in code and instead of binding
local variables just write code to concatenate the string before you
use it as a filter. You would be amazed how much faster it runs too.
BIND is a dog slow process that gets worse the more you use it - so
don't use it most all the time. It's a poor practice. The only things
I ever BIND are my functions functions. Clarion functions are bound
implicitly. Making the filter string on the fly also means you can
optimize the filter string for SQL. Once again it gets even faster.
Without doing this to some extent you can end up with an app that is
worse in SQL then TPS. If you do it can be far faster. It makes that
much difference.
A ERROR 401 means you have a bind problem nearly all the time. It is
best if you learn to project all and only those fields you need.. In
TPS apps all fields are projected all the time even if not projected
in the view. In SQL you have to bear the burden to reap the benefits.
You only get what you ask for. In truth it is better that way.
Reports are one of those areas I always hated a lot. Now I like them
more than anything. The clients know exactly what they hate and it
looks like your report<G>. Reports need to change easily. It is one of
the things I learned years ago. It may be perfect one day and
unacceptable the next. Make it easy to change and keep your clients
happy. Quick reports changes will win every time. Never charge a lot
for a an easy report change. It is what keeps clients happy for many
years.
On 10 Jul 2006 11:35:58 -0400, Guest 3 wrote:
>I was hoping to find out if there exists a utility to read .clw files that will
>detect VIEW file fields that are used in source but are not PROJECTed in the
>view.
---------------------------------------
Paul Blais - Hayes, Virginia
|