>Yeah, Jim alerted me to that. I thought I had checked all the links when I moved the material from esolserv to my new host..and FrontPage didn't complain about a broken link. It's back up now.


Thanks, Craig.

From your article: Deleted Records
How you handle deleted records can have a huge affect on Rushmore speed, especially if you have a very large table with lots of deleted records. Creating an index like INDEX ON DELETED() TAG Del and then issuing SET DELETED OFF will make your queries run faster.

I think, you meant SET DELETED ON here.

Also from your article So, it may take longer to actually build the index and run the query than to just run the query. My advice is, unless you have a HUGE amount of data, to not build the index and let Rushmore determine if one is needed.

What is HUGE here?

SiteMstr has ~2mln.records, TranMstr has about 5mln. and CMRView has ~30 rec.

Unfortunately, TranMstr doesn't have a town field, so I must join to SiteMstr (use only primary address - PrefCode='P') to then filter particular towns.
I'm thinking about doing TranMstr+SiteMstr first (would result ~100000 rec.), then index it on town, then do the last join to CMRView. What do you think?