My Access front-end bloats!

I am developing an Access 2000 application but I develop it in Access 2003 in
2000 mode. I have a problem that my front-end increases heavily in size
without me storing any data at all.

I've seen some links on this issue and I'm not using images, I'm not
importing any data. It increases its size just view data. I've checked every
recordset to see that they close correctly and they do.

Could it be the 2003-2000 mode that makes it bloat?

"Rauken" wrote in message
...

I am developing an Access 2000 application but I develop it in Access 2003
in
2000 mode. I have a problem that my front-end increases heavily in size
without me storing any data at all.

During the development process, this normally occurs. You can set the
compact on close to automatically deal with this problem.

What happens is any form, or anything you modify is actually saved to a new
spot, and the old stuff remains in place. So, during development, likely a
few times during the day you will compact as a normal habit.

This concept of "OLD" data actually NOT being deleted until you compact goes
back a long ways in terms of computer history. Even 20 years ago when
products like dbaseII hit the scene, it had a pack command to purge deleted
records. In other words, when you delete a record, space is not re-claimed
at that instant, but only when a "pack" command is issued. Reclaiming disk
space would take WAY too much performance away from the product (and
especially with multiple users...as they all must resolve to a particular
spot on the disk drive..and that can't change during using the file). You
can imagine what would happen if you deleted a record near the START of a
large file, and then tried to move the HUGE file down to fill in the small
gap/hole created by the deletion of ONE tiny record (if the file was a
million records large...you would then have to move down 1 million records
after deleing one stupid record!).

It is also possible you are very new to computers and databases, and are not
aware of the 20+ year history as to the fact that most database systems
don't re-claim deleted record space, nor shrink the file while it is in use.
So, given that you are new computers and databases, what is common fair and
common knowledge in the computer industry likely seems strange to new users
of this technology. However, re-claming of disk space is just not workable.
However, *some* databases do re-cycle deleted records, but once again, the
file don't shrink when in fact records are deleted.

Of course, when editing forms, reports etc, these also actually don't save
over the old data, but are copied. So, lots of modifying of your forms and
reports etc does make a copy of what you modified. So, simply compact often
during development. When the database is put into production , then the
bloat problem is (should be) a non issue. Those users are not modifying the
forms, and report designs. You should also give each user a mde (you do
this..right????...however, remember that only the SAME version of ms-access
can create a mde for its version - so, a2003 can't create a a2000 mde file).

When you modify data in a table, *usually* the data can be written back to
the same spot, so bloat is not much of a problem in this case either. To be
fair, the issue of development and modifying forms is related to the issue
of not reclaiming disk space, but at lest records can *often* be written
back to the same spot on disk..where as for forms..this don't happen.


Could it be the 2003-2000 mode that makes it bloat?

Hum, I don't think so. (if you worked with the previous version...and only
NOW are experience bloat, then you might be on to something).

I am running and testing and developing a number of a2000 applications with
a2003, and not seen anything out of ordinarily.

I do however, "right" before I deploy the mdb, I put it on a pc with a2000
and create the mde file which users should get. So, I would try running the
application as a mde, and see how that helps (note, that using a mde assumes
you have a split database).

There is a good list of things to check and things that cause un-unnecessary
bloating problems he

http://www.granite.ab.ca/access/bloatfe.htm

Good luck...and welcome to the new world of databases!

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.attcanada.net/~kallal.msn

Hi!

Thanks for the reply. No I'm not new to computers but I kind of new to
Access development. I did some work in Access 2.0 many years ago (I think
that app is still running in Access 95). Since Access 2.0/Paradox 3.5 I've
into VB programming and now .NET and C#. For me Access is a step backwards.
Back then I thought Access was a great tool. Now I think it works perfect
for a back-end of smaller apps but front-end... hmm no. I guess it works
perfect if you want to get something together quite fast and few users but
other than that? I would have created this front-end in VB just as fast but
the customer is always right :-)

I recall the bloating "problem" but didn't realize that an app would grow
from 1 mb to 15 mb in a couple of days. Yes I'm modyfing forms and reports
quite a lot so I guess that's the "problem".

Developing in Access is kind of strange. In VB I would put whatever controls
on the form I would need no more no less. In Access I have to remove a lot
Access functionality that I don't want the user to have. As I said I use to
be an Access fan but I guess I've grown up :-)

Anyway thanks a lot for your reply, it's great when people take their time
to help people.


"Albert D. Kallal" skrev:

"Rauken" wrote in message
...

I am developing an Access 2000 application but I develop it in Access 2003
in
2000 mode. I have a problem that my front-end increases heavily in size
without me storing any data at all.

During the development process, this normally occurs. You can set the
compact on close to automatically deal with this problem.

What happens is any form, or anything you modify is actually saved to a new
spot, and the old stuff remains in place. So, during development, likely a
few times during the day you will compact as a normal habit.

This concept of "OLD" data actually NOT being deleted until you compact goes
back a long ways in terms of computer history. Even 20 years ago when
products like dbaseII hit the scene, it had a pack command to purge deleted
records. In other words, when you delete a record, space is not re-claimed
at that instant, but only when a "pack" command is issued. Reclaiming disk
space would take WAY too much performance away from the product (and
especially with multiple users...as they all must resolve to a particular
spot on the disk drive..and that can't change during using the file). You
can imagine what would happen if you deleted a record near the START of a
large file, and then tried to move the HUGE file down to fill in the small
gap/hole created by the deletion of ONE tiny record (if the file was a
million records large...you would then have to move down 1 million records
after deleing one stupid record!).

It is also possible you are very new to computers and databases, and are not
aware of the 20+ year history as to the fact that most database systems
don't re-claim deleted record space, nor shrink the file while it is in use.
So, given that you are new computers and databases, what is common fair and
common knowledge in the computer industry likely seems strange to new users
of this technology. However, re-claming of disk space is just not workable.
However, *some* databases do re-cycle deleted records, but once again, the
file don't shrink when in fact records are deleted.

Of course, when editing forms, reports etc, these also actually don't save
over the old data, but are copied. So, lots of modifying of your forms and
reports etc does make a copy of what you modified. So, simply compact often
during development. When the database is put into production , then the
bloat problem is (should be) a non issue. Those users are not modifying the
forms, and report designs. You should also give each user a mde (you do
this..right????...however, remember that only the SAME version of ms-access
can create a mde for its version - so, a2003 can't create a a2000 mde file).

When you modify data in a table, *usually* the data can be written back to
the same spot, so bloat is not much of a problem in this case either. To be
fair, the issue of development and modifying forms is related to the issue
of not reclaiming disk space, but at lest records can *often* be written
back to the same spot on disk..where as for forms..this don't happen.


Could it be the 2003-2000 mode that makes it bloat?

Hum, I don't think so. (if you worked with the previous version...and only
NOW are experience bloat, then you might be on to something).

I am running and testing and developing a number of a2000 applications with
a2003, and not seen anything out of ordinarily.

I do however, "right" before I deploy the mdb, I put it on a pc with a2000
and create the mde file which users should get. So, I would try running the
application as a mde, and see how that helps (note, that using a mde assumes
you have a split database).

There is a good list of things to check and things that cause un-unnecessary
bloating problems he

http://www.granite.ab.ca/access/bloatfe.htm

Good luck...and welcome to the new world of databases!

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.attcanada.net/~kallal.msn

"Rauken" wrote in message
...

Back then I thought Access was a great tool. Now I think it works perfect
for a back-end of smaller apps but front-end... hmm no. I guess it works
perfect if you want to get something together quite fast and few users but
other than that?

It really depends on what data engine you use with ms-access. Really,
ms-access is just a VB development environment with a different forms models
then what you got in VB. The code and syntax in ms-access is the same as VB.
Further, if you use VB, c++, or ms-access to connect to a database, the
performance will NOT be different between these systems. So, there are
companies right not that have 1000 ms-access users all hitting the same
database at the same time. So, ms-access is just a IDE like VB or any other
development product. You build the application in ms-access, but the data
engine you connect to is you choice (Oracle, sql-server, JET, etc).

I would have created this front-end in VB just as fast but
the customer is always right :-)

Hum, if you have experience with both platforms, then you will generally
find ms-access production rates in the range of 2, or 3 times that of VB.
That means a$8000 project in ms-access will eat up $24,000 of VB developer
time. There is little, of any comparing in the productivity of VB
development to ms-access development when talking about data centric
applications.

If you take a look at the following screen shots of some ms-access showing
data, it is interesting to note that you can see in some screen shots a
button that will launch a new form to display he one record. What is
amazing, is that you can open a form in ms-access to a particular invoice,
or part number or whatever with ONE line of code (imagine that...one line
code?). You just don't get that kind of leverage in VB forms.

Look, VB is a great development platform, but it is not a data centric
product. VB thus rather pales as compared to ms-access for projects that
just have to edit data. On the other hand, I would not try and write a
pac-man game in ms-access, but you certainly can and would in VB. So, they
are VERY different tools. VB is a general application development tool, and
not a data centric product. If VB was anywhere near ms-access in terms of
development rate, then ms-access would have been dumped long ago (and, I
would have dumped VB long ago too!).

So, while ms-access shares the same code base and compiler as VB6, and even
the same language syntax as VB, the forms and object model are complete
different from VB.


Developing in Access is kind of strange. In VB I would put whatever
controls
on the form I would need no more no less.

Actually, your vb controls generally need a LOT more! And, the lack of
properties for the VB controls is very problematic for editing of data.
There are differences between the VB concepts of controls, and ms-access
controls (for example, we have both .text, and .value, and .oldvalue...that
is 3 different ways to use values on a control, and they are required for
any kind of decent data entering. In VB...what..you have one (text) property
to deal with? (how simple, and yet this means VB seems easer, but then you
turn around have to write all kinds of code to duplicate what is standard
and so often needed for general editing).

You can view a list of fields in design mode, and simply drag the field from
the field list to the screen,a nd you get a data bound control, *and* even a
label is placed on the screen. For laying out data fields on a screen,
ms-access runs circles around the VB editor. And, what ever happened to
highlighting a field, and then using the duplicate button in VB?


In Access I have to remove a lot
Access functionality that I don't want the user to have. As I said I use
to
be an Access fan but I guess I've grown up :-)

Hum, about all I have to turn off is the record selection, record navigation
, auto re-size. Also, once you setup a control the way you let, you go
format-set contorl defaults, and then everything that follows is the same.

The trick in ms-access, or any development tools is learning what exists,
and the how those features HELP YOU!

For example, access forms have both a on-open event, and a on-load event
(this is sorely missing in VB). What this brilliant dividing means is that
the on-open event (should) has code for verifying tings, or testing for a
conditions that would PREVENT the form from actually loading. You can't do
this in VB, as the form is already loaded and displayed......or you can come
up with some VERY painful workarounds. So, we use the on-open event to test
for a record lock, or perhaps some other criteria that will NOT allow the
form to open. This means the form's on-load event will not occur, and the
form will not display. In vb, you can't do this, since your code to "test"
if the form can be loaded has to be placed outside of the form (and, that is
silly...the code belongs WITH the form). Of course, once the on-open event
does occur, then the more familiar on-load event runs. Obviously, in the
on-load event stuff like setting up variables, setting some defaults, or
even setting values of controls is possible (you can't set the values of
controls in the on-open event...it is too soon). So, not only do we have two
events here (where VB forms has only one), but that divisions means as a
developer you now know were to look for certain kinds of code (verify code
in "open", and setup code in "load"). This kind of division makes the
development process more consistent, and actually easier since now we have a
spot for code that will prevent the form load. In VB, every man comes up
with a complete different approach and solution to this problem..and the
result is a terrible lack of consistency.

The other area where VB forms lack re the data event. We have tons of events
here, on insert, before update, after update, on delete...this list is VERY
long. To duplexes these standard functions that you need on a daily bases
in VB takes REAMS and REAMS of code.

I could write for pages and pages but, simply put, VB is a general tool, not
hot knife through butter when it comes to data centric applications. They
are very different tools, and sure...we all kind of have our "favored"
system, or some system that we are more familiar with...but that changes
little in how ms-access runs circles around VB for data centric projects.



--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.attcanada.net/~kallal.msn

Rauken wrote:

I recall the bloating "problem" but didn't realize that an app would grow
from 1 mb to 15 mb in a couple of days. Yes I'm modyfing forms and reports
quite a lot so I guess that's the "problem".

Yes, that's quite typical.

Developing in Access is kind of strange. In VB I would put whatever controls
on the form I would need no more no less. In Access I have to remove a lot
Access functionality that I don't want the user to have. As I said I use to
be an Access fan but I guess I've grown up :-)

What kind of functionality do you remove? I can't say I do except in
very specific situations. Such as where some users are allowed read
only access while others are allowed update/add access as well.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

Ok. The functionality that I have to remove is securing the application so
that users can't modify forms, reports etc. I don't want my users to have
access functions (menu) when clicking the right mouse button.

"Tony Toews" skrev:

Rauken wrote:

I recall the bloating "problem" but didn't realize that an app would grow
from 1 mb to 15 mb in a couple of days. Yes I'm modyfing forms and reports
quite a lot so I guess that's the "problem".

Yes, that's quite typical.

Developing in Access is kind of strange. In VB I would put whatever controls
on the form I would need no more no less. In Access I have to remove a lot
Access functionality that I don't want the user to have. As I said I use to
be an Access fan but I guess I've grown up :-)

What kind of functionality do you remove? I can't say I do except in
very specific situations. Such as where some users are allowed read
only access while others are allowed update/add access as well.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

I agree that VB controls need a lot more code. On the other hand I have total
control of the application. I've ended up with a mix of coding forms in VB
style, using unbound forms and controls and some controls are databound.

What Microsoft should do is to convert the VB controls to Access and make
them Access "native". In the standard controls of Access I am missing so much
of what can be done in VB.

Then we have classes, how is that used in Access. Are people developing
object oriented apps in Access or do they just put code in modules and forms?

I can agree that Access works for small no of users but what about upgrading
an application? Let's say you have users from different countries (like in my
case), using VB the problem with having the users to run the same version of
Access is gone.

I have a no of questions about Access and maybe you could turn me into an
Access fan again? :-)



"Albert D. Kallal" skrev:

"Rauken" wrote in message
...

Back then I thought Access was a great tool. Now I think it works perfect
for a back-end of smaller apps but front-end... hmm no. I guess it works
perfect if you want to get something together quite fast and few users but
other than that?

It really depends on what data engine you use with ms-access. Really,
ms-access is just a VB development environment with a different forms models
then what you got in VB. The code and syntax in ms-access is the same as VB.
Further, if you use VB, c++, or ms-access to connect to a database, the
performance will NOT be different between these systems. So, there are
companies right not that have 1000 ms-access users all hitting the same
database at the same time. So, ms-access is just a IDE like VB or any other
development product. You build the application in ms-access, but the data
engine you connect to is you choice (Oracle, sql-server, JET, etc).

I would have created this front-end in VB just as fast but
the customer is always right :-)

Hum, if you have experience with both platforms, then you will generally
find ms-access production rates in the range of 2, or 3 times that of VB.
That means a$8000 project in ms-access will eat up $24,000 of VB developer
time. There is little, of any comparing in the productivity of VB
development to ms-access development when talking about data centric
applications.

If you take a look at the following screen shots of some ms-access showing
data, it is interesting to note that you can see in some screen shots a
button that will launch a new form to display he one record. What is
amazing, is that you can open a form in ms-access to a particular invoice,
or part number or whatever with ONE line of code (imagine that...one line
code?). You just don't get that kind of leverage in VB forms.

Look, VB is a great development platform, but it is not a data centric
product. VB thus rather pales as compared to ms-access for projects that
just have to edit data. On the other hand, I would not try and write a
pac-man game in ms-access, but you certainly can and would in VB. So, they
are VERY different tools. VB is a general application development tool, and
not a data centric product. If VB was anywhere near ms-access in terms of
development rate, then ms-access would have been dumped long ago (and, I
would have dumped VB long ago too!).

So, while ms-access shares the same code base and compiler as VB6, and even
the same language syntax as VB, the forms and object model are complete
different from VB.


Developing in Access is kind of strange. In VB I would put whatever
controls
on the form I would need no more no less.

Actually, your vb controls generally need a LOT more! And, the lack of
properties for the VB controls is very problematic for editing of data.
There are differences between the VB concepts of controls, and ms-access
controls (for example, we have both .text, and .value, and .oldvalue...that
is 3 different ways to use values on a control, and they are required for
any kind of decent data entering. In VB...what..you have one (text) property
to deal with? (how simple, and yet this means VB seems easer, but then you
turn around have to write all kinds of code to duplicate what is standard
and so often needed for general editing).

You can view a list of fields in design mode, and simply drag the field from
the field list to the screen,a nd you get a data bound control, *and* even a
label is placed on the screen. For laying out data fields on a screen,
ms-access runs circles around the VB editor. And, what ever happened to
highlighting a field, and then using the duplicate button in VB?


In Access I have to remove a lot
Access functionality that I don't want the user to have. As I said I use
to
be an Access fan but I guess I've grown up :-)

Hum, about all I have to turn off is the record selection, record navigation
, auto re-size. Also, once you setup a control the way you let, you go
format-set contorl defaults, and then everything that follows is the same.

The trick in ms-access, or any development tools is learning what exists,
and the how those features HELP YOU!

For example, access forms have both a on-open event, and a on-load event
(this is sorely missing in VB). What this brilliant dividing means is that
the on-open event (should) has code for verifying tings, or testing for a
conditions that would PREVENT the form from actually loading. You can't do
this in VB, as the form is already loaded and displayed......or you can come
up with some VERY painful workarounds. So, we use the on-open event to test
for a record lock, or perhaps some other criteria that will NOT allow the
form to open. This means the form's on-load event will not occur, and the
form will not display. In vb, you can't do this, since your code to "test"
if the form can be loaded has to be placed outside of the form (and, that is
silly...the code belongs WITH the form). Of course, once the on-open event
does occur, then the more familiar on-load event runs. Obviously, in the
on-load event stuff like setting up variables, setting some defaults, or
even setting values of controls is possible (you can't set the values of
controls in the on-open event...it is too soon). So, not only do we have two
events here (where VB forms has only one), but that divisions means as a
developer you now know were to look for certain kinds of code (verify code
in "open", and setup code in "load"). This kind of division makes the
development process more consistent, and actually easier since now we have a
spot for code that will prevent the form load. In VB, every man comes up
with a complete different approach and solution to this problem..and the
result is a terrible lack of consistency.

The other area where VB forms lack re the data event. We have tons of events
here, on insert, before update, after update, on delete...this list is VERY
long. To duplexes these standard functions that you need on a daily bases
in VB takes REAMS and REAMS of code.

I could write for pages and pages but, simply put, VB is a general tool, not
hot knife through butter when it comes to data centric applications. They
are very different tools, and sure...we all kind of have our "favored"
system, or some system that we are more familiar with...but that changes
little in how ms-access runs circles around VB for data centric projects.



--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.attcanada.net/~kallal.msn

I notice on your homepage that you are a skier? So am I! I come from Sweden
and the Winter is here sooon, I can't wait. I also try to go the Alps at
least once a year. Never been to Canada, I'd love to go to Whistler one day,
heard a lot about the great powder skiing :-)

I agree in many things you write but I can't think of Access as a front-end
for 1000 user's. What about upgrading etc? My client has users in six
countries and they must use the same version of Access, in VB they wouldn't
have to care about that.

I am really missing the form controls in VB. The Access controls really lack
functionality. For an example. How would you solve the problem with a listbox
that needs a checkbox in front of each item? Or a blank row at the top of a
combobox? I have solved them but I had to do workarounds.

I was thinking about classes in Access and how to use them. Saw your article
on your homepage. Ok writing apps in VB is more code but also total control
of the application. During the years I've created my own code bank in VB and
that's why I said it wouldn't take me longer to write the same app in VB. For
this app I'm starting from scratch with Access and I realize I have forgotten
some of the functions.





"Albert D. Kallal" skrev:

"Rauken" wrote in message
...

Back then I thought Access was a great tool. Now I think it works perfect
for a back-end of smaller apps but front-end... hmm no. I guess it works
perfect if you want to get something together quite fast and few users but
other than that?

It really depends on what data engine you use with ms-access. Really,
ms-access is just a VB development environment with a different forms models
then what you got in VB. The code and syntax in ms-access is the same as VB.
Further, if you use VB, c++, or ms-access to connect to a database, the
performance will NOT be different between these systems. So, there are
companies right not that have 1000 ms-access users all hitting the same
database at the same time. So, ms-access is just a IDE like VB or any other
development product. You build the application in ms-access, but the data
engine you connect to is you choice (Oracle, sql-server, JET, etc).

I would have created this front-end in VB just as fast but
the customer is always right :-)

Hum, if you have experience with both platforms, then you will generally
find ms-access production rates in the range of 2, or 3 times that of VB.
That means a$8000 project in ms-access will eat up $24,000 of VB developer
time. There is little, of any comparing in the productivity of VB
development to ms-access development when talking about data centric
applications.

If you take a look at the following screen shots of some ms-access showing
data, it is interesting to note that you can see in some screen shots a
button that will launch a new form to display he one record. What is
amazing, is that you can open a form in ms-access to a particular invoice,
or part number or whatever with ONE line of code (imagine that...one line
code?). You just don't get that kind of leverage in VB forms.

Look, VB is a great development platform, but it is not a data centric
product. VB thus rather pales as compared to ms-access for projects that
just have to edit data. On the other hand, I would not try and write a
pac-man game in ms-access, but you certainly can and would in VB. So, they
are VERY different tools. VB is a general application development tool, and
not a data centric product. If VB was anywhere near ms-access in terms of
development rate, then ms-access would have been dumped long ago (and, I
would have dumped VB long ago too!).

So, while ms-access shares the same code base and compiler as VB6, and even
the same language syntax as VB, the forms and object model are complete
different from VB.


Developing in Access is kind of strange. In VB I would put whatever
controls
on the form I would need no more no less.

Actually, your vb controls generally need a LOT more! And, the lack of
properties for the VB controls is very problematic for editing of data.
There are differences between the VB concepts of controls, and ms-access
controls (for example, we have both .text, and .value, and .oldvalue...that
is 3 different ways to use values on a control, and they are required for
any kind of decent data entering. In VB...what..you have one (text) property
to deal with? (how simple, and yet this means VB seems easer, but then you
turn around have to write all kinds of code to duplicate what is standard
and so often needed for general editing).

You can view a list of fields in design mode, and simply drag the field from
the field list to the screen,a nd you get a data bound control, *and* even a
label is placed on the screen. For laying out data fields on a screen,
ms-access runs circles around the VB editor. And, what ever happened to
highlighting a field, and then using the duplicate button in VB?


In Access I have to remove a lot
Access functionality that I don't want the user to have. As I said I use
to
be an Access fan but I guess I've grown up :-)

Hum, about all I have to turn off is the record selection, record navigation
, auto re-size. Also, once you setup a control the way you let, you go
format-set contorl defaults, and then everything that follows is the same.

The trick in ms-access, or any development tools is learning what exists,
and the how those features HELP YOU!

For example, access forms have both a on-open event, and a on-load event
(this is sorely missing in VB). What this brilliant dividing means is that
the on-open event (should) has code for verifying tings, or testing for a
conditions that would PREVENT the form from actually loading. You can't do
this in VB, as the form is already loaded and displayed......or you can come
up with some VERY painful workarounds. So, we use the on-open event to test
for a record lock, or perhaps some other criteria that will NOT allow the
form to open. This means the form's on-load event will not occur, and the
form will not display. In vb, you can't do this, since your code to "test"
if the form can be loaded has to be placed outside of the form (and, that is
silly...the code belongs WITH the form). Of course, once the on-open event
does occur, then the more familiar on-load event runs. Obviously, in the
on-load event stuff like setting up variables, setting some defaults, or
even setting values of controls is possible (you can't set the values of
controls in the on-open event...it is too soon). So, not only do we have two
events here (where VB forms has only one), but that divisions means as a
developer you now know were to look for certain kinds of code (verify code
in "open", and setup code in "load"). This kind of division makes the
development process more consistent, and actually easier since now we have a
spot for code that will prevent the form load. In VB, every man comes up
with a complete different approach and solution to this problem..and the
result is a terrible lack of consistency.

The other area where VB forms lack re the data event. We have tons of events
here, on insert, before update, after update, on delete...this list is VERY
long. To duplexes these standard functions that you need on a daily bases
in VB takes REAMS and REAMS of code.

I could write for pages and pages but, simply put, VB is a general tool, not
hot knife through butter when it comes to data centric applications. They
are very different tools, and sure...we all kind of have our "favored"
system, or some system that we are more familiar with...but that changes
little in how ms-access runs circles around VB for data centric projects.



--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.attcanada.net/~kallal.msn

en artículo , Rauken en
escribió el 9/24/04 08:53:

Hi!

Thanks for the reply. No I'm not new to computers but I kind of new to
Access development. I did some work in Access 2.0 many years ago (I think
that app is still running in Access 95). Since Access 2.0/Paradox 3.5 I've
into VB programming and now .NET and C#. For me Access is a step backwards.
Back then I thought Access was a great tool. Now I think it works perfect
for a back-end of smaller apps but front-end... hmm no. I guess it works
perfect if you want to get something together quite fast and few users but
other than that? I would have created this front-end in VB just as fast but
the customer is always right :-)

I recall the bloating "problem" but didn't realize that an app would grow
from 1 mb to 15 mb in a couple of days. Yes I'm modyfing forms and reports
quite a lot so I guess that's the "problem".

Developing in Access is kind of strange. In VB I would put whatever controls
on the form I would need no more no less. In Access I have to remove a lot
Access functionality that I don't want the user to have. As I said I use to
be an Access fan but I guess I've grown up :-)

Anyway thanks a lot for your reply, it's great when people take their time
to help people.


"Albert D. Kallal" skrev:

"Rauken" wrote in message
...

I am developing an Access 2000 application but I develop it in Access 2003
in
2000 mode. I have a problem that my front-end increases heavily in size
without me storing any data at all.

During the development process, this normally occurs. You can set the
compact on close to automatically deal with this problem.

What happens is any form, or anything you modify is actually saved to a new
spot, and the old stuff remains in place. So, during development, likely a
few times during the day you will compact as a normal habit.

This concept of "OLD" data actually NOT being deleted until you compact goes
back a long ways in terms of computer history. Even 20 years ago when
products like dbaseII hit the scene, it had a pack command to purge deleted
records. In other words, when you delete a record, space is not re-claimed
at that instant, but only when a "pack" command is issued. Reclaiming disk
space would take WAY too much performance away from the product (and
especially with multiple users...as they all must resolve to a particular
spot on the disk drive..and that can't change during using the file). You
can imagine what would happen if you deleted a record near the START of a
large file, and then tried to move the HUGE file down to fill in the small
gap/hole created by the deletion of ONE tiny record (if the file was a
million records large...you would then have to move down 1 million records
after deleing one stupid record!).

It is also possible you are very new to computers and databases, and are not
aware of the 20+ year history as to the fact that most database systems
don't re-claim deleted record space, nor shrink the file while it is in use.
So, given that you are new computers and databases, what is common fair and
common knowledge in the computer industry likely seems strange to new users
of this technology. However, re-claming of disk space is just not workable.
However, *some* databases do re-cycle deleted records, but once again, the
file don't shrink when in fact records are deleted.

Of course, when editing forms, reports etc, these also actually don't save
over the old data, but are copied. So, lots of modifying of your forms and
reports etc does make a copy of what you modified. So, simply compact often
during development. When the database is put into production , then the
bloat problem is (should be) a non issue. Those users are not modifying the
forms, and report designs. You should also give each user a mde (you do
this..right????...however, remember that only the SAME version of ms-access
can create a mde for its version - so, a2003 can't create a a2000 mde file).

When you modify data in a table, *usually* the data can be written back to
the same spot, so bloat is not much of a problem in this case either. To be
fair, the issue of development and modifying forms is related to the issue
of not reclaiming disk space, but at lest records can *often* be written
back to the same spot on disk..where as for forms..this don't happen.


Could it be the 2003-2000 mode that makes it bloat?

Hum, I don't think so. (if you worked with the previous version...and only
NOW are experience bloat, then you might be on to something).

I am running and testing and developing a number of a2000 applications with
a2003, and not seen anything out of ordinarily.

I do however, "right" before I deploy the mdb, I put it on a pc with a2000
and create the mde file which users should get. So, I would try running the
application as a mde, and see how that helps (note, that using a mde assumes
you have a split database).

There is a good list of things to check and things that cause un-unnecessary
bloating problems he

http://www.granite.ab.ca/access/bloatfe.htm

Good luck...and welcome to the new world of databases!

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.attcanada.net/~kallal.msn

Rauken wrote:

Ok. The functionality that I have to remove is securing the application so
that users can't modify forms, reports etc.

This can be handled by making an MDE. Although they'll still be able
to modify tables, queries and macros.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm