If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
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? |
#2
|
|||
|
|||
"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 |
#3
|
|||
|
|||
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 |
#4
|
|||
|
|||
"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 |
#5
|
|||
|
|||
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 |
#6
|
|||
|
|||
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 |
#7
|
|||
|
|||
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 |
#8
|
|||
|
|||
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 |
#10
|
|||
|
|||
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 |
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Images in a database | Franz | General Discussion | 10 | October 7th, 2004 09:35 AM |
Upload Image | Jason MacKenzie | General Discussion | 1 | September 1st, 2004 04:38 AM |
Access Shared Database Front End Increases in size | Jason | General Discussion | 2 | August 11th, 2004 04:15 PM |
Access user profile | Michael Breitsameter | General Discussion | 7 | July 23rd, 2004 07:47 AM |
Useless Access 2003 | tired, angry, sucidial and bored | General Discussion | 10 | July 21st, 2004 11:52 PM |