Access - FE/BE ran Analyze Performance - It suggested an Index????

Hello Experts....
I have a split DB FE/BE and I ran the Performance Analyzer and the Results suggested adding an Index for a Field in one of my tables.

I was in the Front End when I ran it.....  I Clicked Optimize and I realized that I was in the Front End and not the Back End....

I then Opened the Back End and Ran the same Performance Analyzer... (the one in Access itself)  In the Back End It gave NO Suggestions....  However, I looked at the table of the one field I had clicked "Optimize" when I was in the Front End and there wasn't any change to that Field....  I looked at the Settings in the table and for that field the "Indexed" was still set to NO...

So that begs a couple questions...

A) Should you allow Access to Optimize a Table from the Front End or does it even work....
B) Should you just take the suggestion from the FE and go do it in the BE...

OR
Did I just screw up that table when I click on Optimize from the FE???
wlwebbAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

SimonCommented:
The analyzer would need to see your queries to make optimisation suggestions, so it makes sense to run it from the front-end database and then manually apply those changes to the tables in the backend. With a split FE/BE architecture, the optimiser cannot modify the table index in the linked table, so you'd have to do it manually.

I think that answers both your A) and B) questions. I am  sure that clicking optimize in the FE cannot screw up your linked table in the BE.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
wlwebbAuthor Commented:
Thanks!  I'll see if anyone else comments as well
0
SimonCommented:
That's fine. In the meantime... Does the analyzer-suggested index make sense to you, given the queries, forms and reports that you have defined in the FE? Does the table in question already have a primary key defined? Do you join that table to others in any queries or lookup values from the column that it is suggested you create an index on?

Just bear in mind that the analyzer wasn't created to deal with FE/BE databases. It would be able to apply the suggestions it made if you had the whole database in a single file. If you pushed the FE/BE thing a little further and put the BE on MSSQL, you could use the SQL Server Database Engine Tuning Advisor on the backend. The difference is that in that case the backend is an active server rather than a passive file.
0
The Ultimate Tool Kit for Technolgy Solution Provi

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more!

Nick67Commented:
I think Simon has you squared away.
The optimizer isn't going to hose anything up.
Indexing can be a bit of a black art.

Good table design (autonumber as Primary Key, foreign keys are autonumbers from other tables) takes care of most of it.
An index is almost always recommended on fields used in JOINS (see above :)
An index on fields used in criteria (Between ThisDate and ThatDate) can also help performance.
Indexes on text fields used in criteria or heaven-forbid JOINS can REALLY boost query performance

BUT

Indexes have overhead.
The system has to create, maintain and update them.
So useless indexes create overhead for little gain.

ALSO

Access has an upper limit of 32 indexes per table
And Access insists that each foreign key has an index.
32 seems like a lot -- and depending on your application it might be.
I've hit it, though, and it was one of the drivers behind moving the backend to SQL Server to move beyond that limit.
So, on your main table, you may wish to considered the Analyzers advice -- and disregard it.
0
wlwebbAuthor Commented:
Simon....

 In the meantime... Does the analyzer-suggested index make sense to you, given the queries, forms and reports that you have defined in the FE? ....

They did make sense.  Both were on Yes/No fields that I used to filter (ie: ClosedShift and VoidShift)  

I am relatively new to DB so SQLServers are beyond me at this point but both you and Nick have given some good info, just not sure I'm ready to tackle that yet.....

I'm going to close this an award the points
0
wlwebbAuthor Commented:
Thank you for the input..........!!!!
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.