Using same module with 2 front ends

[ryetee]

I have a small system that consists of a back end data base and 2 front ends.
having 2 front ends was a historic reason but they cover 2 distinct processes in the system.

I now have the need for using the same module(s) in both front ends.
Each has a copy which is fine if nothing changes but when it does I have to apply the changes made (or copy over in its entirety) from one front end to the other.

Although this is no big deal I can forsee it slipping through the net.

Can 2 front ends access the SAME module and if so how?

 

[vbaInet]

You certainly can:

1. Create a db with the relevant modules in it (ensuring that the relevant functions are Public)
2. Save it as an accde or an mde (depending on which version it is)
3. Go to References, locate the accde/mde and add it.

All the functions will now be available within your db. Think of it as your reference library.

 

[ryetee]

You certainly can:

1. Create a db with the relevant modules in it (ensuring that the relevant functions are Public)
2. Save it as an accde or an mde (depending on which version it is)
3. Go to References, locate the accde/mde and add it.

All the functions will now be available within your db. Think of it as your reference library.

Only just got around to looking at this so have the usual couple of questions!
Firstly how do add the accde file to my database. Not sure where "references" is. I've googled it but can't seem to find it!
Secondly if I need to debug code in the accde module can I do this and if so how?

back to google.....

EDIT........

OK I've found it and added it and it works!
I do now have another question.
When I added the file I obviously had to tell Access where it was.
Do I have to do this again when releasing to the test and eventually production environments? This would be more painful than copying the module to all front ends when it changes.
Stiill need to know if I need to debug code in the accde module can I do this and if so how?

 

[spikepl]

If you put the referred-to database file in the same folder as the database file that refers to it then Access is clever enough to find it, provided that the previous reference no longer exists.

An if you need to debug code in that module then you have to operate in the accdb. If stand alone then you just recreate the accde afterwards. If not stand alone then you have to have a version for debugging using the accdb's and then one for issuing using the accde.

 

[ryetee]

If you put the referred-to database file in the same folder as the database file that refers to it then Access is clever enough to find it, provided that the previous reference no longer exists.

An if you need to debug code in that module then you have to operate in the accdb. If stand alone then you just recreate the accde afterwards. If not stand alone then you have to have a version for debugging using the accdb's and then one for issuing using the accde.

Thanks spikel

On the debug bit do I have to copy the module back into the front end to debug.

What I have at the moment is frontend.accdb and the modules are kept in modules.accde with the former referencing the latter. I presume to debug i can't use the modules.accdb version but have to copy the module I want to debug back into frontend.accdb?

 

[ryetee]

If you put the referred-to database file in the same folder as the database file that refers to it then Access is clever enough to find it, provided that the previous reference no longer exists.

An if you need to debug code in that module then you have to operate in the accdb. If stand alone then you just recreate the accde afterwards. If not stand alone then you have to have a version for debugging using the accdb's and then one for issuing using the accde.

Spikel - just come across a funny with the bit you mention in your first paragraph. I've just released the front end together with the referred to database to my users PC. I've relinked all the tables and as you point out access is clever enough to know where the referred to file is. In fact when you go into tools, references and highlight the one in question it tells you exactly where it is.

All good so far BUT, I display the date and time on the first form that is displayed. These fields are bound (?) to date() and time(). They work in my environment but in the user's environment they are displayed as #Name?
There is also another funny in that a control that is used to exit the system doesn't work. It appears there are unpredictable results. The functions in the referred to module have nothing to do with the date and time or exit button.

If I go into VB and delete the reference and reinstate it then everything works fine. This could become more of a pain than keeping the module in the 2 front ends.

Any ideas?

 

[Acropolis]

Why not just have one front end, and when the user opens it set it to look up which version they require and have two switchboard forms or similar, and direct them to the appropriate one?


Keeps everything in one place and makes updating in the future easier?

 

[ryetee]

Why not just have one front end, and when the user opens it set it to look up which version they require and have two switchboard forms or similar, and direct them to the appropriate one?


Keeps everything in one place and makes updating in the future easier?

It's an option that I don't want to introduce just yet on a release that is now in user test. There are security implications as well which just add some complexity to the new front end. Besides that the end user will no doubt want to keep the front ends separate.

 

[vbaInet]

If the implementation (e.g. parameter types, return type etc) of your Class/Module changes then I see no benefit of having a reference library simply because the Front End that calls those functions/subs will also need to change. If this were an Excel environment were users can call/use the functions/subs then this would be beneficial.

And even if the implementation doesn't change, you will still need to test both the reference library and the front end and in some cases your front end might break which might require further amendment.

 

[ryetee]

If the implementation (e.g. parameter types, return type etc) of your Class/Module changes then I see no benefit of having a reference library simply because the Front End that calls those functions/subs will also need to change. If this were an Excel environment were users can call/use the functions/subs then this would be beneficial.

And even if the implementation doesn't change, you will still need to test both the reference library and the front end and in some cases your front end might break which might require further amendment.

Reason for doing this is that 2 front ends use the same function(s). If any of the the functions need changing I have to copy between front ends. I can see this being forgotten so was after a solution where function only appears in one place. It is already becoming more of a pain than it is worth.

 

[vbaInet]

My question to you is what changes in the function? And why should the function keep changing?

 

[ryetee]

My question to you is what changes in the function? And why should the function keep changing?

I see your point. Probably won't change unless there's a deeply hidden bug.
You've convinced me - ditch the reference and stick it back into the 2 front ends.

 

[vbaInet]

If you put the reference db in a shared location and point to that location, your FEs wouldn't have problems referencing it.

But as already highlighted, any changes made to the ref db will need to be tested on both FEs and in most cases if one FE is broken following the change, the other FE will too be most likely broken. So yes, in your case I think it's best to duplicate the code.