Some good tips and pointers for speeding up data access to my back end tables

[kelly draper via AccessMonster.com]

my app is split with front end on local machines and back end on shared
drive on network. that connection is horrible slow so my app takes about 2
minutes to open and I have a couple of forms in it that have listboxes used
to find a record with the results for all the various search listboxes
showing up in 1 subform. the listboxes search for different things so I
programmatically change the child and master fields of the subform
depending on which listbox the user is currently searching from. because of
the slow network connection, the changing of the child and master fields
takes a while too.
so what I'm hoping for are some good tips and pointers for optimizing my
app,tables,data etc. to squeeze out every ounce of speed i can get anywhere
i can get it.
thanks.

 

[kelly draper via AccessMonster.com]

P.S. and I know your probably gonna wanna slap me for this but, I dont set
primary keys or indexes for my tables. I know primary keys and indexes are
required for certain kinds of relationships, but other than that, why is
that a bad thing. some of my tables dont have fields with all unique
values. what can i do about them.
thanks.

 

[Jeff Conrad]

See MVP Tony Toews excellent performance tips here:

http://www.granite.ab.ca/access/performancefaq.htm

--
Jeff Conrad
Access Junkie
Bend, Oregon

in message:

 

[John Vinson]

P.S. and I know your probably gonna wanna slap me for this but, I dont set
primary keys or indexes for my tables. I know primary keys and indexes are
required for certain kinds of relationships, but other than that, why is
that a bad thing.

For one thing, sorting the data in a table (if you have an Order By on
the form) or searching for records in a table is MUCH MUCH FASTER if
the field you're sorting or searching is indexed. If one of your
concerns is slow performance - one of the first solutions is
appropriate indexing!

some of my tables dont have fields with all unique
values. what can i do about them.

You'll need to do SOMETHING about them. If you have two records for
which *every single field is identical*, then there is no way
whatsoever that you can identify which of those records is which,
either in a query or for deleting a record. A table without a Primary
Key isn't really a table at all.


John W. Vinson[MVP]