SQL Server migration?

[SuzyQ]

I have an access application using an access database. The data is split
from the application. The data file size is 9656KB, the application file
size is 5820KB and is installed on individual workstations. Everything has
been working smoothly until recently when the entire system has slowed to a
crawl when 2 or more people are logged in. My network administrator added
ram to the server thinking that would help, but it hasn't. He thinks we
might need to migrate to SQL server. I'm not sure how or even if I would
need to modify my code to talk to SQL server data. I don't know much about
SQL server, and although I am an experienced programmer, it is mostly old
school. I have written several access applications, but consider myself a
newbee in access as well. Can anyone give me some advice?

Thanks

 

[Douglas J. Steele]

9656 KB? That's less than 10 MB, which is miniscule for Access. It would
seem to be overkill to move to SQL Server (and just because the application
is on SQL Server does not mean it'll be any faster. In fact, it's more
likely to be slower)

Check what Tony Toews has in his Microsoft Access Performance FAQ at
http://www.granite.ab.ca/access/performancefaq.htm

 

[SuzyQ]

I know I'm not giving much info (mainly because I don't have any right now),
but do you have any ideas what might be causing the slow down?

 

[Douglas J. Steele]

Did you check the reference I gave you?

 

[ricol]

Witout knowing to much about your problem. I would try to do Compress/Repair
in the data mdb. Should be done at least once a month or more often depending
on how much update activity you have.

 

[SuzyQ]

I actually do this weekly, because a lot gets deleted on a regular basis.

 

[SuzyQ]

I'm looking at it. I'll go though and check off and test each item to see if
I can make the app faster. I don't have any sub datasheets set up on the
tables, the users only see forms (I don't know if I understand this one, but
if it is the subdata sheet that can be set up while viewing the table
directly - I don't allow that anyway - everything is done via forms). So the
first change I made was to turn off track name autocorrect. We'll see what
happens after their workstations get updated. If that doesn't work, I'll
continue through the list.

 

[David W. Fenton]

miniscule

Pet peeve:

It's spelled: minuscule.

(look it up!)

 

[Douglas J. Steele]

Pet peeve:

It's spelled: minuscule.

(look it up!)

I did. Both are acceptable spellings.

 

[David W. Fenton]

I did. Both are acceptable spellings.

Well, I didn't know that. My dictionaries prefer "minuscule" but do
include the other spelling as a variant. I think the variant is bad
because it gets the etymology wrong, but it's obviously been
accepted for a long time (it's in two of my dictionaries from the
mid-70s). Seems to me like something of an eggcorn:

http://eggcorns.lascribe.net/

which is a defined as a case where someone comes up with a logical
explanation for a variant of a common word or phrase. I guess "mini"
comes from "minus" so it's not so far off etymologically.

 

[SuzyQ]

Well I guess it pays to go into the office once in a while. The slowness
issue was caused by an ini file I had given to two of the users that allows
them to switch between archive data and live data. The instructions were to
set the path in the ini file to back end data they needed, and then to
comment out the instruction so that it didn't go through recreating the links
to the data everytime the application loaded. This was done over a year ago
and I had forgotten about it. I went in to watch the application load and
knew immediately the cause. I commented out the line in the ini file and now
the app loads instantly. Thanks for the help. The performance faq sheet
will come in handy though. I will be using it to make other performance
changes as necessary.