"Jeff Eckermann" <jeff_eckermann(at)yahoo(dot)com> wrote in message
> How much testing have you done? I have never had a
> problem with this, but then, I don't have to deal with
> any huge datasets.
I don't have any large datasets; largest table at present only has about
Had created 2 views against the largest recordset for testing, one with a
WHERE clause, and 2 bound forms, each using one of the views as a
recordsource. The form using the view without the WHERE clause had the
conditions in the WHERE clause used as a filter.
I didn't put in timing code, but the filtered form seemed a little slower.
Dropped and rebuilt the test views, forms, etc. and now don't see much
Phillipe had noticed difference between Access 2000 and Access 2002/2003
mdb, but I had already been using 2002/2003, as will be distributing runtime
executable to my employees.
Can't explain the difference in performance from first testing, but will try
using filters in upcoming production version unless real world performance
> > I change the SQL of pass-through queries dynamically
> > at runtime to use as
> > record sources for reports. That wouldn't work for
> > forms, as not updatable.
> > Is the best approach to use an updatable view as the
> > record source, then
> > change the view definition at runtime as with a
> > passthrough query?
> Why would you need to do this? If you want to show
> different data to different users, then you reference
> the user name (e.g. current_user or session_user) in
> your view definition.
Was just creating unique name for the temporary view, for which string
containing current_user would certainly be easier. All of my employees will
have similar table permissions at the present time, as small office and
David P. Lurie
In response to
pgsql-odbc by date
|Next:||From: Philippe Lang||Date: 2004-08-06 16:22:09|
|Subject: Re: Filter equivalent for Access bound form|
|Previous:||From: Thomas Bache||Date: 2004-08-05 23:01:05|
|Subject: SSL as unpriviledged user|