What was/is your "largest" access project

[amorosik]

After 100 posts there is still someone who insists on recommending the division between user interface and data
Perhaps it is not clear to you that the OP has probably already evaluated the matter and has decided, for the reasons he considers important, to maintain the current architecture without modifications
The fact that many forum participants have found it beneficial to divide the user interface and data does not mean that in any case it is a preferable thing, in the case of DenverDb evidently the thing for him is not preferable compared to the current state

 

[amorosik]

I see absolutely no reason to do a split, especially when I need to create 40 new tables, 10 new forms, and 10 new reports each day.

Have patience but this thing, the need to create 40 new data tables each day, intrigues me a lot
It is as if I had a new customer, and to create documents for that customer, the tables containing the headers and lines of the documents were duplicated, and the new header/line contains only data of new customer

So my question is: the need to add data tables to the program is due to the fact that the procedure is still being refined, and therefore you are completing the data structure, or you are using new tables to store new data which structure are similar to existing tables?
And therefore the creation of new data tables will be an ordinary procedure even when the Access procedure will be completely defined

 

[isladogs]

Sorry about George. If you like, I am more than happy to go back and delete all of my posts in this thread.

Whilst nobody is asking for that to be done, perhaps a moderator would be willing to move everything from about post #36 to a new thread as the lengthy discussion about @DenverDb's database has completely taken over the OPs thread

 

[The_Doc_Man]

After 100 posts there is still someone who insists on recommending the division between user interface and data
Perhaps it is not clear to you that the OP has probably already evaluated the matter and has decided, for the reasons he considers important, to maintain the current architecture without modifications
The fact that many forum participants have found it beneficial to divide the user interface and data does not mean that in any case it is a preferable thing, in the case of DenverDb evidently the thing for him is not preferable compared to the current state

Actually, it is quite clear he doesn't want to split. My suggestion was made as a way to break his 2 Gb limit. But your very next post regarding adding so many tables exposes the other problem that will eventually crop up... the limits on the number of Access objects - in which a split would also help. Yes, it IS clear he has a pathological aversion to splitting. I am not going to "rag" him on that. The problem will resolve itself at some point when he reaches whichever limit he reaches first.

 

[Pat Hartman]

After 100 posts there is still someone who insists on recommending the division between user interface and data

I think you missed the point of the insistence on a split. the app is very close to the 2M limit for Access. That means it will stop working tomorrow or next week given the rate at which new objects are added and that can lead to data loss. The fact that the OP is insistent on not splitting is not relevant because the database is about to reach the technical limit of an Access database. He is at the point of having no choice and so it is better to do it before the crash to avoid data or object loss.

 

[amorosik]

I think you missed the point of the insistence on a split. the app is very close to the 2M limit for Access. That means it will stop working tomorrow or next week given the rate at which new objects are added and that can lead to data loss. The fact that the OP is insistent on not splitting is not relevant because the database is about to reach the technical limit of an Access database. He is at the point of having no choice and so it is better to do it before the crash to avoid data or object loss.

Nothing is missed, don't worry
When you informed the op that the Access limits are as above, you did what you could to help him
When he bumps his nose against the impossibility of continuing then it will be time to change his vision

 

[amorosik]

On Access Limit Microsoft page there is "... max 2048 of OPEN table..."
DenverDb has 4100 table on the 'monster', but probably fewer OPEN tables at the same time
If so, then what is the limit of tables an Access procedure can have (internal tables or links to tables on external db) ?

 

[amorosik]

The problem will resolve itself at some point when he reaches whichever limit he reaches first.

Yess, obviuosly
And I'm really curious to understand what these limits are on a real project

 

[Gasman]

Guys,
You can take a horse to water, but you cannot make it drink.

 

[Pat Hartman]

Here's a link to the limits.

Microsoft Access 2016 Maximum Limits and Specifications

Microsoft Access 2016: maximum limits and specifications ... Microsoft Access training in Toronto, Ontario, Canada. Our instructor-led courses are offered in downtown Toronto.

www.avantixlearning.ca

and another one by @isladogs

Access Specification issues

Microsoft publishes a list of Access specifications and limits. Most of the information is correct. This article discusses some specification items that are misleading, out-of-date or inaccurate

www.isladogs.co.uk

 

[The_Doc_Man]

Guys,
You can take a horse to water, but you cannot make it drink.

You can lead a junior programmer to ideas but you cannot make him/her think.

Not intended to apply to anyone participating in this thread, of course...

 

[NauticalGent]

ou can take a horse to water, but you cannot make it drink.

But you can hold it's head underwater until it stops moving...

 

[Gasman]

But you can hold it's head underwater until it stops moving...

Now Now