Single project composed of different sections - how supply different versions?

[amorosik]

, I’m intrigued to know how you would accomplish this.

I actually asked in the group because I wanted to understand if you know the solution

 

[amorosik]

One of the many advantages of maintaining one version and restricting according to e.g. job role or license type is that the app doesn’t need to be reinstalled

Yes, of course
But I would like to experiment with the second system, the possibility of cutting out only the necessary code

 

[CJ_London]

I wanted to understand if you know the solution

The solution I know but would not use would be copy/paste so now you understand. I’m interested in knowing your solution or at least understanding why the two solutions suggested do not meet your requirements and some idea of what you envisage as being an acceptable solution

 

[jwcolby54]

It feels to me like you are heading down a road with many forks. And more every day as new folks want different combinations of things. It sounds like a maintenance nightmare.

I designed a system which I called C2DbPresentLevelSecurity of Groups / users / User groups / Forms / Group forms... all maintained inside of access. I then set up what people belonged to what groups. I then set up what groups (not people) could see and perform what activities on what forms and reports. I am a class kind of guy so it is all driven by the form or report class loading as a form loads, then calling into my C2DbPLS library checking what group(s) the current user belongs to, and from there whether the form loading is allowed to - be visible, it might load but not be visible or not load at all (close back down), allow edits (does the group(s) have edit rights?), Allow Adds (does the group(s) have rights to add records, and AllowDeletes (can the group(s) delete records in that form?).

It is not a trivial undertaking to set up the data but once set up it is just a matter of adding new users to groups. I call it table driven programming because these tables mentioned above drive the program rather than hard coding such things. A small maintenance nightmare rather than a huge maintenance nightmare.

 

[jwcolby54]

That is the road to chaos. My software is always delivered as the same code base. The license key provides the information required to assign functions to groups. Within the app, the administrators can control the usage of forms by individuals by using the internal security which is similar to what is done in the sample app.

So you know "the" solution but are toying with us. I quit, you're on your own. I don't have time to waste on your test. Do not expect me to bother answering future questions you post.

I think we might be dealing with a language problem rather than an intention problem.

 

[CJ_London]

I think we might be dealing with a language problem rather than an intention problem.

The OP has a reputation of asking open ended questions and omits relevant facts about the requirement. Look back though their history. This one is a good example as it relates to this thread.

How to make a large project?

Sometimes these are projects with a few dozen forms, tables, and some code modules But sometimes we are faced with projects that have hundreds of forms, hundreds of reports, dozens of modules even with a lot of code, and in this case we often get close to the limits of the Access environment...

www.access-programmers.co.uk

 

[amorosik]

That is the road to chaos. My software is always delivered as the same code base. The license key provides the information required to assign functions to groups. Within the app, the administrators can control the usage of forms by individuals by using the internal security which is similar to what is done in the sample app.

Also my software is made like this, with a key that activates the authorized functions
And many other software are made like this
But now I want to check other possibilities, I don't understand why this request may seem strange to you
If you don't know how to answer, don't answer

So you know "the" solution but are toying with us. I quit, you're on your own. I don't have time to waste on your test. Do not expect me to bother answering future questions you post.

I'm asking for something, and this means that I don't know it otherwise I wouldn't have asked
It only takes a little effort to understand it

 

[amorosik]

The OP has a reputation of asking open ended questions and omits relevant facts about the requirement. Look back though their history. This one is a good example as it relates to this thread.

How to make a large project?

Sometimes these are projects with a few dozen forms, tables, and some code modules But sometimes we are faced with projects that have hundreds of forms, hundreds of reports, dozens of modules even with a lot of code, and in this case we often get close to the limits of the Access environment...

www.access-programmers.co.uk

"..omits relevant facts about the requirement.."
To understand the request, you just need to know how to read, it's written

 

[CJ_London]

To understand the request, you just need to know how to read, it's written

And if responders ask for clarification it would appear you are too arrogant to answer

I'm off this thread, a complete waste of everyone's time

 

[The_Doc_Man]

While I agree in principle with other members here that this direction of investigation invites a LOT of extra work, I also realize that (a) amorosik is an experimenter and (b) what he suggests would lead to an experiment that would reveal the extra work.

@amorosik - while I don't think this is a productive path, I acknowledge that it is your time to spend in determining the best way to do some of this kind of role separation.

You asked about splitting DB files according to intended purpose/role within the overall application. You didn't specify how you would do the split. I will advise that having multiple back-end files would be counter-productive because you would take away the ability to declare Relational Integrity across the multiple BE files. But if you have one BE and multiple front-end files, at least you would keep everyone synchronized to the same data.

Splitting the FE and the BE into role-based parts would lead towards a dangerously confusing configurations that would make proper configuration management more difficult than it should be, because now you would have to remember which FE talked to which BE, and that would be a really interesting junction table. But a side-effect is that if you had multiple BE files statically linked, you increase your vulnerability to outages if any ONE of the files goes awry. Whereas if it is a singular BE and multiple FEs, only an affected FE and therefore a single FR purpose that would be effected.

Like I said, it is your direction, your time to spend as you see fit. Go for it.

 

[jwcolby54]

I use a library to hold all my code which is common across my apps / clients. Sometimes two libraries. Then the FE mostly has app specific code. Other than that I use a Presentation Level Security system to determine who gets to see what. I would never even consider splitting a database up. That said, if there are tightly controlled bounds, then perhaps a sales database, an accounting database etc. But to try and do this on the fly is just nuts IMHO.

 

[jwcolby54]

And now I am unsubbing from this thread.

 

[amorosik]

You said this was a test because

I never wrote that this is a test

you already know the answer.

I never wrote that I knew the answer

You want to know if any of us know YOUR answer.

I never wrote that I wanted to know if you know MY answer
I wrote that I wanted to know if you know the answer to the question posed
And finding an answer to the question posed is the main goal of every person who inserts a post

That is a total disrespect of our time and I'm not playing.

I am sincerely sorry that you may think that my question was not respectful, but I have to tell you that it is not so.

 

[amorosik]

I use a library to hold all my code which is common across my apps / clients. Sometimes two libraries. Then the FE mostly has app specific code. Other than that I use a Presentation Level Security system to determine who gets to see what. I would never even consider splitting a database up. That said, if there are tightly controlled bounds, then perhaps a sales database, an accounting database etc. But to try and do this on the fly is just nuts IMHO.

"..on the fly.." it's something that has never been asked

 

[The_Doc_Man]

@amorosik - as you can see from the answers you got, your question seemed confusing to some. I suggest that you consider that at least some of the responses you got MIGHT have been misunderstandings.

Having functionally separate front-ends will already be a configuration nightmare. It is good that you were not looking to do this dynamically i.e. on the fly, because that would probably run into more problems than you might ever want to see. I warned you earlier and commented on split schemes that could work vs. those that probably would not. If you choose to go down the "functionally separate front ends" path, I will have little to offer in the way of help. I have always built monolithic FE files that simply refused to open forms or enable various fields based on a table of user roles and authorizations. I never tried any other way so have no advice that I haven't already given.

 

[amorosik]

Yes, I understand, and so I'll explain the request again
I didn't ask to create a system that 'dynamically' configures itself to have the features of Version1 or Version2 or any other version

The request is: having a project created with Access that I'll call Version0 (I'm talking about the front-end part only, not the data) and containing 100 forms, 100 reports, 100 modules, how can I build a system that can compose the Version1 application composed of 50 forms, 30 reports, 10 Version0 modules, similarly how to prepare the Version2 application composed of 10 forms, 3 reports, 2 Version0 modules

So the complete project will remain Version0, and this project can be updated regularly, both with corrections to any anomalies and with the addition of new features
Every time the Version0 project is modified, I have to recreate Version1 and Version2 (...VersionN) with the limited set of forms, reports, modules, which will be assigned to them
This is the work I would like to speed up, the regeneration of the various subprojects every time changes are made to the main project
Both the main project Version0 and the subprojects Version1 and Version2 connect to the same database, in my case via odbc to a db server external to the Access procedures

The final effect is similar to that obtained by always keeping the same identical project and limiting the functionality via software with an activation key or similar systems
In this case the main project is cut and various subprojects are packaged

 

[Josef P.]

Every time the Version0 project is modified, I have to recreate Version1 and Version2 (...VersionN) with the limited set of forms, reports, modules, which will be assigned to them

You could create an application in which you configure the different versions and then create the different versions similar to the msaccess-vcs.
In principle, you could even use the msaccess vcs to create it. You just have to make sure that the appropriate files are available in the folder of the specific version.

 

[Edgar_]

It could be as simple as this:

Sub CopyVersions()
    ' Version1: delete query1 and form1
    CreateObject("Scripting.FileSystemObject").CopyFile CurrentProject.FullName, CurrentProject.Path & "\Version1.accdb", True
    With CreateObject("Access.Application")
        .OpenCurrentDatabase CurrentProject.Path & "\Version1.accdb"
        .DoCmd.DeleteObject acQuery, "query1"
        .DoCmd.DeleteObject acForm, "form1"
        .CloseCurrentDatabase
        .Quit
    End With
    
    ' Version2: delete report1 and form1
    CreateObject("Scripting.FileSystemObject").CopyFile CurrentProject.FullName, CurrentProject.Path & "\Version2.accdb", True
    With CreateObject("Access.Application")
        .OpenCurrentDatabase CurrentProject.Path & "\Version2.accdb"
        .DoCmd.DeleteObject acReport, "report1"
        .DoCmd.DeleteObject acForm, "form1"
        .CloseCurrentDatabase
        .Quit
    End With
End Sub

Check the attached file, go to mod2 module and run the CopyVersions sub.

 

[amorosik]

You could create an application in which you configure the different versions and then create the different versions similar to the msaccess-vcs.
In principle, you could even use the msaccess vcs to create it. You just have to make sure that the appropriate files are available in the folder of the specific version.

Yes great ideaAnd so the sequence could be:
1- changes to Version0
2- creation of text files with MasAccess-Vcs
3- the program for the regeneration of Version1 takes all the text files, copies them into its own directory, deletes unnecessary files, launches the creation of Access files from text files
Even if, thinking about it again, there is not a big difference between going from intermediate text files or directly deleting forms, reports, modules from the main file Version0, in essence it is the same thing

 

[amorosik]

It could be as simple as this:

Sub CopyVersions()
    ' Version1: delete query1 and form1
    CreateObject("Scripting.FileSystemObject").CopyFile CurrentProject.FullName, CurrentProject.Path & "\Version1.accdb", True
    With CreateObject("Access.Application")
        .OpenCurrentDatabase CurrentProject.Path & "\Version1.accdb"
        .DoCmd.DeleteObject acQuery, "query1"
        .DoCmd.DeleteObject acForm, "form1"
        .CloseCurrentDatabase
        .Quit
    End With
   
    ' Version2: delete report1 and form1
    CreateObject("Scripting.FileSystemObject").CopyFile CurrentProject.FullName, CurrentProject.Path & "\Version2.accdb", True
    With CreateObject("Access.Application")
        .OpenCurrentDatabase CurrentProject.Path & "\Version2.accdb"
        .DoCmd.DeleteObject acReport, "report1"
        .DoCmd.DeleteObject acForm, "form1"
        .CloseCurrentDatabase
        .Quit
    End With
End Sub

Check the attached file, go to mod2 module and run the CopyVersions sub.

Yes, this is also a great idea
I hadn't thought of making Version1 or Version2 by taking Version0 and deleting things