What was/is your "largest" access project

That's interesting jdraw. I don't use Google so I can't help you. Try checking the AUG website. Alternatively, ping George Hepworth and Maria Barnes.
 
Do I understand you correctly: you want to create 25 individual database files (split by domain, each file has tables, forms, etc.)
Tip: Look at the concept of Access add-ins. You could then open them from a main application and basically have only one application open.
With one restriction: the forms cannot be used as subforms between add-ins.

Note: Since we're pretty much undermining the thread topic "What was/is your "largest" access project" here in my opinion, please open a new thread if you want to discuss the topic of sharing with add-ins.
Agreed. This particular project is unique to itself in multiple ways. The spirit of this thread, at least, is to showcase working, production, projects that involve multiple users, or multiple components ("hybrids apps"), or complex processing and so on.
Discussing this project in that same context misses that point.
 
Thanks for the link George(y)
David- a very interesting presentation and approach highlighting your communication skills and focus on ensuring customers/clients understand the message/data.
 
Agreed. This particular project is unique to itself in multiple ways. The spirit of this thread, at least, is to showcase working, production, projects that involve multiple users, or multiple components ("hybrids apps"), or complex processing and so on.
Discussing this project in that same context misses that point.
Sorry about George. If you like, I am more than happy to go back and delete all of my posts in this thread.
 
Sorry about George. If you like, I am more than happy to go back and delete all of my posts in this thread.
Not my call in anyway. I was just pointing out that the discussion went well beyond the original intent of the discussion and drifted into something else entirely.
 
Sorry about George. If you like, I am more than happy to go back and delete all of my posts in this thread.

No, DO NOT DO SO! It is valuable for others to see the issues and the ebb-and-flow of ideas in an investigation on this kind of question. Even if many of us disagree with your viewpoint, the discussion and exploration of ideas ALWAYS benefits folks searching for new ideas. While I think you are misguided in your viewpoint on splitting a DB, I absolutely respect that you have put in a lot of work on a complex issue.

Therefore, leave the discussion as-is, please.
 
I agree with the others - leave the posts in the thread. In my view this application works for David and his customers/clients. He knows the subject matter better than anyone. As for the database structure, it does what he wants and needs and has done so for years. He has identified options for when the database grows to the extent it requires restructuring. Although his methods may not be suited to the majority of Access-based applications, they certainly have proven themselves to him.
We all could learn something from his enthusiasm and use of graphics as a primary means of communicating the meaning and importance of data to the client.
We all can continue to suggest and promote database splitting(FE/BE) as a standard practice, while recognizing that some applications (PEP specifically) are not "standard".
 
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
 
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
 
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
 
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.
 
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
 
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) ?
 
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
 
Guys,
You can take a horse to water, but you cannot make it drink. :)
 
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...
 

Users who are viewing this thread

Back
Top Bottom