I don't really think this is much possible.
I mean, if they add a new field to a table, then the 100's of lines of code,
and even forms, and even reports would have to modified to show that extra
And, what kind of training does it take to learn how to add a new field to a
table? (answer...very little!!!).
I mean, I used some 4th GL systems in the past, but at the end of the day,
any changes of value required some coding.
You *can* make some things easier. for example, I built a security screen
and manger. While my code still uses the built in security system, for sure
placing some forms and menus on top of ms-access, the process became MUCH
Here is the screen shots and article as how I did this:
However, the above does not involve changing the design of tables, or
database structure. further, the built in screens that allow you to modify,
or add fields to a table is ALREADY VERY EASY. So, while my article is great
on making the UI easy, that example does not modify the database structure.
The instant you jump into building something that changes its design as you
move along is the instant that your users must become developers. IF you can
figure out a way to avoid this problem, then you will be the next Bill
Gates. This concept is just not really possible, and not seen anything that
would do otherwise in my long career in this industry.
Further, why should users create tables? How can you have any management
system if new tables are being created all the time? This means that NO
structure can exist. How can historical data and reporting occur if the
current tables and designs are in a state of change?
So, I not exactly sure what you are looking for, but a system that relies on
new tables, and changes in table designs is really DOOMED to failure.
It seems to me the problem is that no one wants to sit down and define the
problem that needs to be solved. so, you are being asked to make something
that does not requite any problem solving!!!
I would figure out what they need to accomplish, and then build system that
accomplishes this task. That is the way the industry has worked from day
one, and I don' see how you can change the need for good designs by allowing
users to make tables.
Creating tables in ms-access is not the hard part. Having good table
designs, and understanding a relational database modeling is most certainly
an issue here....
I might be missing your question, but I just don't see how history data and
reporting can occur when table and designs are in a constant state of
change. How will past data and history be managed in such a system?
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada