Running vba code external file (1 Viewer)

[gstylianou]

Hello,
Is it possible to run a vba code from an external file instead of from Access?

Thanks in advance

 

[arnelgp]

what actually are you trying to accomplish?

 

[gstylianou]

what actually are you trying to accomplish?

I hace an accde file and i want to modify the code

 

[arnelgp]

i think you cannot edit the code in an .accde file.

 

[gstylianou]

i think you cannot edit the code in an .accde file.

Yes I know that's why I m looking a way to run the code via external file

 

[theDBguy]

Do you want the ACCDE to run the external code?

 

[gstylianou]

Do you want the ACCDE to run the external code?

Actually I exported all modules from my accdb file into Notepad++ converting them in vba and what I want is after the creation of accde file I need to rum the codes via Notepad++ files

 

[theDBguy]

Actually I exported all modules from my accdb file into Notepad++ converting them in vba and what I want is after the creation of accde file I need to rum the codes via Notepad++ files

Thanks for the additional information. Just curious, is there any reason why you can't use a ACCDB?

 

[June7]

I have used VBScript to connect to acccdb and run macro and VBA procedure. No idea if will work with accde.

 

[gstylianou]

Thanks for the additional information. Just curious, is there any reason why you can't use a ACCDB?

I cannot because I don't want anyone can modify the code etc...

 

[gstylianou]

I have used VBScript to connect to acccdb and run macro and VBA procedure. No idea if will work with accde.

Could you please give me a sample on how can I do iti ?

 

[June7]

Dim ObjAccess
Set ObjAccess = CreateObject("Access.application")
ObjAccess.visible = false
ObjAccess.OpenCurrentDatabase("C:\Users\Owner\June\LL\Umpires.accdb")
ObjAccess.UserControl = False
ObjAccess.Run "HelloTest"
'ObjAccess.DoCmd.RunMacro "MyMacro"
ObjAccess.Quit
Set ObjAccess = Nothing

 

[The_Doc_Man]

I cannot because I don't want anyone can modify the code etc...

June7 has suggested an approach, but my problem is more conceptual. If you build an ACCDE that has the ability to trigger something in an external .ACCDB, it would not be long before the people you don't want to modify the code will figure out how you do it and will repeat your process - in effect, modifying the code you didn't want modified and opening a big door for mischief.

It sounds like you want to modify something dynamically without modifying it. OR... The idea of running external code makes it appear that you have code you want to run but that nobody else should be allowed to run. The normal way to do that is to make the ACCDE file sensitive to the identity of its users and then just make the restricted segments refuse to run if the wrong person is running.

I cannot see any other reason for your request than a back-door to run code that others shouldn't see. If that is not what is going on, enlighten us.

 

[isladogs]

With ACCDB files, it is easy to run code from external sources including the use of Access add-ins or by adding external databases as library references.

As you already know, the purpose of creating ACCDE files is to protect existing code. You cannot add/delete references. You cannot add, edit or delete code nor can you import or export code. You can still use add-ins though not to alter existing code.
If you were able to circumvent these restrictions, it would make creating ACCDE files fairly pointless.

If you want the code edited you need to do so in the developer copy of the ACCDB, then convert to a new ACCDE and distribute that to your end users

 

[Pat Hartman]

Actually I exported all modules from my accdb file into Notepad++ converting them in vba and what I want is after the creation of accde file I need to rum the codes via Notepad++ files

We are all having a lot of trouble trying to figure out what you need. If you give us the business case you are trying to model rather than telling us what technical solution you want, perhaps we will have a little more success.

You seem to be asking how to modify the code in an existing .accde. Just to remind you, all the source code has been removed from the .accde so there is NO CODE TO MODIFY. PERIOD.

Is your real business problem that you need a way of updating/replacing the FE of an application on a user PC without being on site?

 

[gstylianou]

Good morning,

I have an accdb file that will be distributed to some users, In this file there are some parameters (inside the code ) that will change in the future such as Paths, URLs, static IP and others. I would like to find a way so these vba modules to be in some external files so when the database will convert to an accde file to can change some parameters and part of the vba code without having to re-distribute the database to users from the beginning due of a serious practical reson.

Of course I know whatever you saying and thanks for the pointers, I was just wondering if anyone had done something similar so I could get some ideas. I know of course that when a database is converted from accdb to accde it is impossible to make changes to the database design as well to the code.

 

[June7]

Exactly how would this prevent "having to re-distribute the database to users from the beginning".

Put parameters that need to change in a table and not hard coded.

 

[gstylianou]

Exactly how would this prevent "having to re-distribute the database to users from the beginning".

Put parameters that need to change in a table and not hard coded.

It's not a good idea because of security issues my friend..! The application can be downloaded from users

 

[theDBguy]

It's not a good idea because of security issues my friend..! The application can be downloaded from users

You can design your code to look for the parameters from the external file, which means you'll have to distribute your database with the external file. However, I am not sure you can stop users from sharing a copy of their files.

 

[The_Doc_Man]

It's not a good idea because of security issues my friend..! The application can be downloaded from users

I believe you are painting yourself into a corner.

You want to have external files - which would be downloaded to the users, right?
But for security you don't want the application to be downloaded? You DO realize that the ACCDE file isn't inherently encrypted, so if someone downloads the ACCDE they can get to the tables easily enough.

You want the file as an ACCDE so it can't be changed. But you want to have supplemental information including code modules in the addendum file - so as to change functionality.

These are self-contradictory goals. You need to come up to the surface and examine what you are really asking. This is a "forest vs. trees" situation.

I'm not trying to bust your chops here, so I'll go on to discuss my thoughts on how close you can come to what you describe.

The "list of extra data" such as URLs and IP addresses and other things could easily be done by having a secondary BE file of a predefined structure, for which the initial file has table definitions but the tables would be either be empty or would only contain whatever you want to use in the base version of your app. This app would ALWAYS have to look for the secondary BE file and map it. You would always have to include this file in the base release. Note that using a secondary BE file means that cross-file relational integrity will be impossible. RI cannot be enforced across files, only across tables in the same file.

At least in theory, as a mapped secondary BE file, it COULD contain code modules - but would ALWAYS have to have the same table names and call interfaces between the ACCDE's FE and this putative back end, no matter what else is in the file. In other words, because of the use of the ACCDE which is immutable, your interfaces would HAVE to be immutable, although what is "behind the scenes" of those interfaces could be anything. The interfaces would have to always be qualified by the name of the DB variable you used to open the secondary file.