All experts are getting nervous here, but I'm really enjoying it.if other answer to the question
Maybe because I'm not an expert and don't mind reading repeated solutions over and over.
All experts are getting nervous here, but I'm really enjoying it.if other answer to the question
I would like to thing you are capable of doing that yourselfThe counting ("..you've got between 10 and 42 months..") needs to be redone
Form with moduless are actually 634
Report with modules are actually 299
Modules of code are actually 109
provide the source for your figuresAlready now they do not appear to be those described in the Microsoft documentation
Yes sure, the sum is 1042, i can do it up to three figuresI would like to thing you are capable of doing that yourself
provide the source for your figures
...
There is also a limit of 1000 modules - which includes forms with code - so if all your forms had code you would be limited to 1000 forms.
...
For the purposes of solving the problem described it was not necessary to explain the specific case
OP is used to listen to other, if other answer to the question
Form with moduless are actually 634
Report with modules are actually 299
Modules of code are actually 109
The counting ("..you've got between 10 and 42 months..") needs to be redone
Sorry but maybe I explained myself badlyPlease provide the link to where I said
Form with moduless are actually 634
Report with modules are actually 299
Modules of code are actually 109
NoAmazing!
Are many of those forms automatically generated
Invoices, items, prices, the usual thingsCan I ask what sort of things they do? Are there lots of forms created just to get the user to answer a question or confirm something?
It grew like this because new features were added to an initial minimal coreStill genuinely interested to understand how it's grown so much. And especially why you need to keep adding forms at a rate of dozens per month!
Still genuinely interested to understand how it's grown so much. And especially why you need to keep adding forms at a rate of dozens per month!
are clearly written to try and demonstrate some form of superior intellect, when actually, all they are doing is reinforcing that he (the OP) has no real desire to comprehend the myriad of advice given or is simply too dim to understand it.For the purposes of solving the problem described it was not necessary to explain the specific case
It sounds a bit like there might be lots of highly bespoke forms for very specific purposes.now I'm trying to understand how to organize things a little better
If only you had written this to start with we would have known exactly what you wanted to find out.No
Invoices, items, prices, the usual things
It grew like this because new features were added to an initial minimal core
And having to add more, now I'm trying to understand how to organize things a little better
You can only create a finite amount of objects on forms, including any that are deleted.If that's the case, it should be possible to create forms that dynamically alter themselves that can be re-used for multiple purposes. If that's true you might be able to delete hundreds of them.
are clearly written to try and demonstrate some form of superior intellect, when actually, all they are doing is reinforcing that he (the OP) has no real desire to comprehend the myriad of advice given or is simply too dim to understand it.
Any time I want to show my user some data or pick something from a list I do it dynamically with a universal form. (Not created on the fly - it already exists - you just alter the text and the source query etc etc.)You can only create a finite amount of objects on forms, including any that are deleted.
This is therefore not recommended under any circumstances, in addition you can't make design changes in a compiled ACCDE version of any Access application, so "on the Fly" changes are a no-no.
You can understand exactly what I wanted by reading post1If only you had written this to start with we would have known exactly what you wanted to find out.
We did, very quickly afterwards you wrote in post #5:You can understand exactly what I wanted by reading post1
Read carefully the last line that YOU WROTE , dismissing any reference to any existing applications, experience, or what it was you were doing that would involve adding dozens of objects every month.The question is: how to organize a project to avoid it reaching dimensions incompatible with the limits of the development environment
All other considerations are useless
All the time, all the timeSorry but maybe I explained myself badly
Fair question. Testing of that type was informal but the project's owner (my direct supervisor) had frequent check & sign-off opportunities. Some of my users agreed to look at things and DID provide feedback. But there was no fifth environment for user acceptance testing. Part of the issue was that we were feeding monthly or weekly reports and acceptance testing was ultimately dependent on whether our reports passed the requirements of our system security overseers. The interfaces for data updates DEFINITELY were user-tested and were passed through multiple stages until we got the first "real" system up. Once the production environment went live, testing of new features was a bit trickier.Did you inadvertently leave out a UAT environment when describing your process? - so the users have a chance to review/verify the functionality expected, implement and test urgent fixes and set up a change log and to get sign off from the users/project owner?
Already now they do not appear to be those described in the Microsoft documentation
All the time, all the time
So you have an app- after decompiling and compacting what is the file size? My guess is nothing like 2gb so likely that is not an issue
Withe regards forms/reports - how many actually have a module? Easy to see in the vba navigation window.