Re: Access replacement
> Belive me. I have eg one system with
> near 100 tables, 200 forms, 50 reports,
> many tons of code, 15 users online,
I guess that is a reasonably sized system,
but with surprisingly few users. But I think
you are pushing the limits of Access there.
> Thats facts :((( Another example ? Old
> access 2.0. 5 branch, few users, but
> mamy data (35.000) in one table,
> (10.000-20.000) in next 3.
I guess that is a lot of data for Access,
but you should realize that there is a reason
that 4GB limits on files have been considered
a problem for years. In the last multi user
system I worked with, your figures above are
more or less how much the main tables grew
My personal impression of Access
is that it's dead easy to make very
simple things. I've made some simple
applications with just a few forms, but
as demands got higher, I've always
left it and shifted to other tools.
Partly this might be beacause I didn't make
the needed effort to learn it properly, but
there are some other reasons as well.
* I've gotten used to OO programming and I
feel that I benefit a lot from using OO.
* As projects grow I want to automate things,
generate code and database schemas,
analyze code with other programs and so on.
Then I want all my source to be plain text files.
* I believe in a layered approach, separating
user inteface, program logic and data
storage. Tools like Access doesn't help much
in this, and a large part of the features in
these tools can't be used if you consider it
a taboo for the GUI code to "know" how data
is stored etc.
* I also often find that it's good to be flexible.
(Thus my layered approach.) I might want
to use a GUI for data entry, but I might also
want to be able to enter data from the web
or from information extracted from emails or
fetched from the internet with a spider.
My typical approach has for several years been
to code as much as I can in Python. (So far it
has only been customer demands that have
stopped me from coding everything in Python.)
I build GUIs in wxPython and right now I use
ZODB for storage, but Python works smoothly
with most SQL databases as well.
For a system as big as 200 forms I am fairly
sure that you will get down in a development
time and maintenance cost of maybe 20%
compared to Access if you use a good object
oriented approach in Python.
For a very small application, and for users who
are not really programmers, I guess it's MUCH
more difficult to write wxPython GUI code than
to click and drag in Access.
But as systems grow you reach a point where
tools like Access are far from optimal. I've worked
with similar tools, and suddenly, you need to
change something that exists in 200 forms. Then
you need to manually point and click in 200 forms,
but you are likely to miss a few... With a smarter
approach this might instead be one change in one
class, or it might be a matter of writing a script
that will make the changes in all your program files.