How to make a large project?

You can probably achieve this with dedicated front ends for specific areas of the business
It's been suggested over and over. But OP is not used to listen to others. :)
 
You can probably achieve this with dedicated front ends for specific areas of the business which only contain objects relevant to that area.

That has been suggested multiple times - the first time around post #15 and I've lost count of the number of times since. However the OP doesn't accept it as a solution. I'm guessing that the point they are trying to make is one (or more) of those apps grows until it hits the access limits. The OP also appears to not accept that that those limits are extremely high.

The actual limits have been stated in the early part of this thread but there is a limit of 32767 objects - forms/report/modules and controls for example. A typical form would have say 100 controls (many will only have 20 or 30) so just looking at forms with an average of 100 controls each, you would be limited to 324 forms - at the lower number of controls, perhaps 1500.

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.

At 35 new forms a month (the OP's stated expectation), you've got between 10 and 42 months before you start hitting the limit.

The solution is to divide and conquer (separate apps, use of libraries for common code/forms/reports) and planning - but whatever the solution decided, it depends on the project specifications - the who, what, where and why - as to what that solution would be. And that the OP is unable or unwilling to provide.

I've been developing in Access for nearly 30 years, anything from small apps to global apps for multi nationals and have never approached the limits of access. The one exception being an app that worked fine on 8gb machines, but some users only had 4gb and it struggled - but this was a memory issue solved with a hardware upgrade and was a long time ago.

And memory usage is down to good design - no huge (50,000+ elements) arrays/collections/dictionaries/recordsets, don't have 100 forms open at the same time, etc
 
At last. An actual description of the mythical Unicorn project.
Absolute worst case you'll possibly need 2 or 3 different front ends, connected to a single proper DBMS.

Only taken the thick end of 100 posts for you to actually write something that made sense.

It is neither mythical nor unicornIt is a classic project
I would dare say simple, but with many objects
And it is not just a matter of overcoming the technical limits of a single file but also of reducing the size of the Access files on which you work Instead of working on a single 100Mbyte file you work on 4 of 25-30 Mbyte each
I hope to get a more secure and stable system

"..Only taken the thick end of 100 posts.."
For the purposes of solving the problem described it was not necessary to explain the specific case
 
The actual limits have been stated in the early part of this thread but there is a limit of 32767 objects - forms/report/modules and controls for example. A typical form would have say 100 controls (many will only have 20 or 30) so just looking at forms with an average of 100 controls each, you would be limited to 324 forms - at the lower number of controls, perhaps 1500.

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.

At 35 new forms a month (the OP's stated expectation), you've got between 10 and 42 months before you start hitting the limit.

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

This is why I said that one of the first things to do is to actually measure what the technical limits are
Already now they do not appear to be those described in the Microsoft documentation
 
Last edited:
if other answer to the question
All experts are getting nervous here, but I'm really enjoying it.
Maybe because I'm not an expert and don't mind reading repeated solutions over and over. :)
 
Last edited:
For the purposes of solving the problem described it was not necessary to explain the specific case

Yes it was!!!!!!!!!

I've been telling you that we cannot be specific when dealing with pure abstraction. When dealing with abstraction, we can ONLY offer generalities. You keep on demanding specifics starting from vague generalities. More than one of us suggested various issues in a "divide and conquer" strategy but even that, which DEFINITELY applies here, wasn't to your liking.

OP is used to listen to other, if other answer to the question

WE GAVE YOU ANSWERS.

But because you dealt in abstractions, WE had to deal in abstractions. And you wanted specifics when we didn't have anything on which to base those specifics. THIS is the kind of situation that wastes our time when we have other people with actual problem descriptions. Your tactic was quite selfish and, forgive me for saying it this way, approached a certain degree of ignorance.

To explain what seems to be a harsh characterization, let me ask a question to illustrate the point, @amorosik ...

If you go to a doctor and say "I don't feel so good" - and that's ALL you say - do you think your doctor will immediately tell you how to combat your condition? Or will that doctor ask for specifics so as to narrow down the issue? If your doctor then says you have to stop smoking hashish, will you listen? Or will you complain to your friends at the hookah bar about your unreasonable doctor who won't answer your questions correctly?

Why is this situation any different? Do you not see that we feel like the doctor with an uncooperative and unresponsive patient? Can you expand your perception of this situation to consider OUR feelings on the subject?

We have obviously not abandoned you. You have gotten responses from multiple senior members well past 80 posts in a technical, single-question thread. Usually, it is the Watercooler that generates long-winded sequences threads in excess of 100 posts.
 
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

Amazing!

Are many of those forms automatically generated or has someone really created all of those manually??

Can 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?

Sounds like a nightmare!

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!
 
Please 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
 
Please 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
Sorry but maybe I explained myself badly

I wrote this (the number of form/report/modules)

You wrote that there is a maximum limit of 1000 forms

After that I pointed out to you that the limit of 1000 forms is not real because in my case it was exceeded
This observation makes me think that the maximum limits of objects as described by Microsoft are not always valid
And should not be taken as absolute constraints
 
Amazing!
Are many of those forms automatically generated
No

Can 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?
Invoices, items, prices, the usual things

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!
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
 
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!

@Bennet it hasn't.

This entire thread (You need to read all it, not just the last two pages), until you managed to get an answer from the OP, has been based on supposition and obscurity on the purpose and ultimately reasoning behind the question, whilst altering the question subtly when not getting an answer they wanted or when someone was asking specifics.

I actually doubt there is any answer that will satisfy the OP as he denies he asked a specific question, when clearly he did.
He apparently knows the limits he has asked about but still wants to know more.

Statements like this
For the purposes of solving the problem described it was not necessary to explain the specific case
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.
 
now I'm trying to understand how to organize things a little better
It sounds a bit like there might be lots of highly bespoke forms for very specific purposes.

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.

Hard to say without knowing more though.
 
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
If only you had written this to start with we would have known exactly what you wanted to find out.
 
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.
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.
 
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.

When a person asks for something, I don't think we can talk about 'superior intellect'
Otherwise this person wouldn't ask
 
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.
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.)

Or maybe the OP is creating a new form for every new product line or something. That could obviously be reduced to one form.

299 reports sounds like it just needs some more dynamic query writing rather than a bespoke query for each.... whatever it is.

109 modules sounds a bit like he might have a new module for every procedure, or be duplicating code. Could probably be consolidated massively.

(Appreciate you know all this. OP may not! (y) Or maybe he is a genius far beyond everyone else here. I'm sort of hoping that's what it turns out to be. :cool:)
 

Users who are viewing this thread

Back
Top Bottom