Re: Filter equivalent for Access bound form - Mailing list pgsql-odbc

Hi,

What I noticed with Access 2000 MDBs under Access 2003 has more to do with a bug than with a performance decrease...

Anyway, it would be interesing to have an idea of the timings you are talking about. I'm not really surprised the view
withthe "built-in filter" gives better results. I always try to push as much code as possible on the server, this is
alwaysfaster. 

What you could try maybe is to link your bound form to a query, itself linked to the linked tables, instead of linking
yourform to the linked tables directly. This might give you slightly better results, and the recordset is still
updatable.Make some tests with an MDE as well! 

Your results, timings are welcome!

Philippe

-----Message d'origine-----
De : pgsql-odbc-owner@postgresql.org [mailto:pgsql-odbc-owner@postgresql.org] De la part de David P. Lurie
Envoyé : vendredi, 6. août 2004 17:32
À : pgsql-odbc@postgresql.org
Objet : Re: [ODBC] Filter equivalent for Access bound form


"Jeff Eckermann" <jeff_eckermann@yahoo.com> wrote in message news:20040805184412.78858.qmail@web20826.mail.yahoo.com...
> 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 10,000 records.

Had created 2 views against the largest recordset for testing, one with a WHERE clause, and 2 bound forms, each using
oneof the views as a recordsource. The form using the view without the WHERE clause had the conditions in the WHERE
clauseused 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 difference.

Phillipe had noticed difference between Access 2000 and Access 2002/2003 mdb, but I had already been using 2002/2003,
aswill 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
versionunless real world performance suffers. 

> >
> > 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 similar tasks. 

David P. Lurie




---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend