Question : Slowness & ODBC timeouts  Access and SQL 2000

SQL Experts--

I have just started @ a company with a homegrown(written 3 years ago) Access 2000 .mdb frontend and ODBC linked SQL 2000 tables in backend (with DTS ) appl. Initially it work well & fast with approx. 60 users split in 2 locations with majority of remote users using a Terminal server.
The data trans. service agents run overnite & a few during the day.
Performance has gone down & besides slowness ( up to 20 minutes back east ) there are ODBC timeouts , the SQL server seems not to be blocking ( only once in a while ) or deadlocking - what has change ?
1. Actually management says - there are FEWER users now then before about 50 now.
2.They have moved the SQL server to an upgraded server box  with 3GB memory , faster CPU,  larger drive RAID 5 config & network people indicate the server is not being overworked (less than 50% capacity) through the server logs.

3. Problem appears the database which is 34GB in size now has many more records - there is 1 history(Hist) table over 1,200,000 records and 145 column fields & some others about 400,000 and then others in the 50,000 range (Curr) current  along with some 60 other less used tables.

4.The Access program calls a SQL (FIND_ID)store procedure to do record_ID lookup & status check in  Hist table  &  Curr table- this is on every Access form (over 250) - open form or recordsource event, report event etc - this routine is peppered throughout .

5. In the program as well there are ALSO many query calls from Acess to create open record sets , fill in parameters & build reports etc. from Hist & Curr. databases and other linked tables .

The program has ODBC linked SQL tables & after log in has a "transfer Database ac_link" routine.
 
I see a querydef as shown below--   GetID ( ) gets the prime record reference ID from the current form & the I_StatusCk --stored prc..
checks existing primeID record in Hist or Curr tables then builds out record with parameter data
Find_ID is used on every form , report etc.. Below - I had to type it might be some typos - but the code does work -- the prblem is Slowness


Public Function Find_ID( )
Dim FIDB as Database, FIQdf as Querydef, FIRst as RecordSet, FISQL as String

FISQL ="EXECUTE I_StatusCk @GetPrime =" & GetID( ) & " , @UserID = '"& GetCurrUser & '"

Set FIDB = CurrentDB
SET FIQdf=FIDB.CreateQueryDef("")
FIQdf.ODBCTimeOut = 300                        '>>>>>>>   Here I can change this to help ODBC timeout - but slowness will continue....

With FIQdf
.Connect=ConSource
'.Prepare=dbQUnprepare
.SQL=FISQL
.ReturnRecords=False
.Execute dbSQLPassThrough
FISQL="SELECT RepStatus.Status FROM RepStatus WHERE"
FISQL=FISQL & "((RepStatus.R_ID)=" & GetID( ) &");"

set FIRst=FIDB.OpenRecordSet(FISQL,dbOpenSnapshot)
FIRst.MoveLast
ARAFind=FIRst![Status]
FIRst.Close
FIQdf.Close
End With
Set FIDB=Nothing

END Function

The  I_StatusCk  SP uses  Cursor s to Update RepairStatusHist records or Insert RepairStatus records -- these are different SQL tables ( but say maybe 10 field columns of data )as well with over a 1,000,000 records.
I know this is vague & I can include more code from SQL side but the point is this Complicated Access-SQL program worked & was fast... NOW it isn't....
What can be done -- minor basis to SQL side ?? my idea was to archive Hist Table by half ... not a fix really & not sure of gain...???



2nd part  here - I have submitted to Access Expert side for conversion mdb to adp -- if this would help & how
I have to fix this by next month with out any major coding changes per IT manager (premise is that it WORKED before and to minimize risk to production). I have proposed to archived off half of Hist table but I do not think this will be much help.
Other option would be moving mdb app to ADP but with over 250 forms, reports , extensive code with modules etc.. Is there an automated transfer or conversion process ?? Would this help this ???
Please help - I am going to post this SQL side as well but the bottle neck again seems to be with the fatclient Access current configuration...

Answer : Slowness & ODBC timeouts  Access and SQL 2000

Do you have a maintenance plan on the sql end to periodically update statistics and/or rebuild indexes?  And on the Access end, have you tried compact/repair the client?  After that look at cpu on the client and server simultaneously, along with network throughput during slow performance to make sure it is the server that is the bottleneck.  Assuming server, your best bet is run the sql profiler tool using the duration profile to capture hopefully a small number of queries that you can focus on for improvement.  Access tends to throw lots of selects at the server so you probably run the profiler for 10 minutes during slow performance, save the results to a database table, then you can run ad-hoc select statement against the stored results grouping by text and summing duration.  This will identify your top problems.  Fixing them could entail looking at hardware, adding indexes, changing Access query, making it a pass-through exec of a proc, etc.