Different front ends - what's best practice

[ryetee]

I have a small system that is used by 2 distinct sets of users.

Historically the system is split into 2 front ends, for the 2 different sets of users, and 1 common backend, the data itself.

There is a third standalone system that should be part of the above system.

I could of course just have 3 front ends with again 1 common backend.

It would be better if it all appeared as one system.

There are, in my mind, two ways to do this

1. Have a 4th front end that is used purely to navigate to one of the other 3 front ends. I presume it is possible to load/start a front end from within another? If so how is that done and are there any issues doing it?

2. Consolidate all the 3 front ends into 1. Have a start up form with 3 options on it to load what were the effective start up for each of the original 3 front ends. I can see advantages/disadvantages with this. One disadvantage is that without a lot of name changes it is difficult to see what forms/reports/queries belong to which system. To me this is quite a big deal so I'd want the advantages to outweigh the disadvantages. Deployment becomes slightly easier I guess, but that's not enough.

Any views or alternate suggestions for this?

 

[JLCantara]

Sol. #2 is the best. One way to avoid complexity, is to keep your 3 menus and make one that links to them...

 

[ryetee]

Sol. #2 is the best. One way to avoid complexity, is to keep your 3 menus and make one that links to them...

That was what I was thinking. I have an extra form with 3 options on.

Option 1. Load form from front end 1
Option 2. Load form from front end 2
Option 3. Load form from front end 3

Problem with this is that it makes maintenance a bit more difficult. The 3 options have completely different functions. Having 3 front ends keeps all the forms/queries/reports apart. If I mix them altogether I lose that. I'm sure there will be some other conflicts as well.

That said if the advantages outweigh the disadvantages or there are issues with doing it the other way then I will go down this route.

 

[JLCantara]

Create 3 groups of object (navigation pane, personalized) then, after importing the objects of a FE, store them in the proper group. This way you keep the original grouping!!!

 

[ryetee]

Create 3 groups of object (navigation pane, personalized) then, after importing the objects of a FE, store them in the proper group. This way you keep the original grouping!!!

Sounds like a plan. I'll give it a go when I get back in. I presume each group has its own set of tables reports firms etc? I presume if I have duplicate names of queries ( oh yes I have!) then I'll need to change one or because they are in different groups die sir matter?

 

[JLCantara]

I knew there was duplication!!! Create a 4th group and store in it any shared object...

 

[ryetee]

I knew there was duplication!!! Create a 4th group and store in it any shared object...

Yep - sussed that out!
Have to do a bit of tweaking but looks easier in the long run than the other option I was looking at.

 

[JLCantara]

Maintenance will be easier and your app will be well organised...

 

[ryetee]

Without a doubt.
Thanks for the pointer.