Limiting Access to Procedures

[Petemush]

In a module, is there any point in having a Public Sub (which is called by an On that simply calls a Private Sub or Function? Therefore really protecting your code? Or is this totally pointless? I'm leaning towards the latter at the moment but please correct me if I'm wrong!

Cheers,

Pete

 

[Petemush]

Sorry, that should read:


In a module, is there any point in having a Public Sub (which is called by an OnSomethingEvent in a form) that simply calls a Private Sub or Function? Therefore really protecting your code? Or is this totally pointless? I'm leaning towards the latter at the moment but please correct me if I'm wrong!

Cheers,

Pete

Really should preview my posts!

 

[Junior1544]

if you want to protect your code, i would suggest using an MDE... the code then get's compiled, and the users can't read, nor modify it... the only problem with that is that you may have to redisign the way a few things work...

--James JHauge@jmjpc.net
Life is change. To deny change is to deny life.

 

[Francescina]

The MDE works exactly as the MDB; the only difference is that you can not modify the MDE (except tables and queries). This means that you need to replace "old" MDE's with newer versions.
This means that it is compulsatory that you transform the architecture of your application to Frontend/Backend.

 

[Junior1544]

not only that, (and thank you for explaining that more) i said some things may need to be re worked because when i was given a db to administer, the way the developer made a few of the reports was to (from the calling form) open the form in design mode, change the filters, and save it... i had to change that to have conditional sql as the record source for it...

--James JHauge@jmjpc.net
Life is change. To deny change is to deny life.

 

[MichaelRed]

Francescina,

I do not understand this requirement.

... means that it is compulsatory that you transform the architecture of your application to Frontend/Backend ...

I have used the "Code" db approach and just added it as a reference - wheather as a .MDB or .MDE doesn't appear to matter, and it also does not appear to be necessary to SPLIT the db.

Further, just implementing the infanous MS Security is another way to 'protect' objects, which also does not require any splitting ...

MichaelRed
m.red@att.net

There is never time to do it right but there is always time to do it over

 

[Junior1544]

the problem with making a mde and not spliting it is if you ever want to make a change to the way the db works, you need to use the source mdb, and then since the tables with correct data is in a file that they can't be easily removed from... so you will lose data... that is what he means when he said with a mde, the db needs to be split...

--James junior1544@jmjpc.net
Life is change. To deny change is to deny life.

 

[MichaelRed]

O.K., but why the MDB at all? Just set up the code db and reference it?

MichaelRed
m.red@att.net

There is never time to do it right but there is always time to do it over

 

[Junior1544]

there is a viable option... I must have missed it

--James junior1544@jmjpc.net
Life is change. To deny change is to deny life.