Speed issues in Access 97

  • Thread starter Thread starter Sandy
  • Start date Start date
S

Sandy

Hi
I have a module in my database where I am creating several
forms on the fly. After creating the forms, I save them
and then display the first form as a subform within my
Main form. The first time I do this it all happens quite
quickly. I then delete the forms and do the process again
and it is really slow. If I delete the forms and close
the database, it is fast again. I am not compacting the
database on close.

Can anyone tell me what actually happens when the database
closes and is there a way to replicate the close database
behaviour at run time.

Any clues, hint or idea about how I can fix my speed
problem would be greatly appreciated.

Thanks in advance
Sandy
 
Why don't you explain what it is that makes it a compelling need to create
forms on the fly. That is, explain what you want to accomplish and see if
there is another approach.

There are certainly situations that I haven't encountered, but I've been
using Access rather heavily since 1993 and I haven't ever had a situation
where I _had_ to, or even where it was _desirable_ to create forms on the
fly.

Larry Linson
Microsoft Access MVP
 
Its a little bit complicated but my client receives some
300 surveys each year and these surveys have about 300
questions that have been answered. The survey questions
change regularly so each time you enter/view the data in a
form, it can be very different.

I wish there was another approach because each version
needs to create around 20-23 forms and saving all the
versions could really blow the database size out. That's
why I figured it would be better to create the forms on
the fly.
 
I wish there was another approach because each version
needs to create around 20-23 forms and saving all the
versions could really blow the database size out. That's
why I figured it would be better to create the forms on
the fly.

How about *one* form which can accommodate any number of questions,
which can change every time you open the database if you wish?

http://www.rogersaccesslibrary.com/Otherdownload.asp?SampleName='At Your Survey 2000'

gives an example. The nub of the issue is that you are apparently
making the very common error of storing one answer per *field* - a
normalized design stores one answer per *record*, in a tall-thin
table. This lets you just change the data in your table (the table of
Questions, frex) rather than restructuring your tables and forms when
the questions change.
 
Back
Top