MDE constraint
Experts,
For the obvious in protecting my forms, reports, queries and macros I am consideing splitting my database and then creating an MDE file.
What functionality does a developer loose? Just want to check before I do something stupid, again.
For the obvious in protecting my forms, reports, queries and macros I am consideing splitting my database and then creating an MDE file.
What functionality does a developer loose? Just want to check before I do something stupid, again.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Not sure about latter releases, but in 2000/2003 macros are creatable and editable.
Also, if you view this as a form of proptection of your forms and reports, note that with automation and the application.Saveastext method, you can get a read-out of the form (sans code) even though you can't open it in design view.
Jim.
Yeah ... I do recall now that Macros are not protected.
Will have to try the SaveAsText ... are you sure about that ? If so, it would render an MDE useless ...
mx
Will have to try the SaveAsText ... are you sure about that ? If so, it would render an MDE useless ...
mx
Microsoft strongly advises AGAINST using Macros. The issue is that, as such, macros cannot be 'debugged' - The distinction here is between MACROS and VBA Modules - which contain executable VBA code.
AW
AW
Well, that's odd because in A2010 there is a brand new full on 'Macro Designer' ... which they seem to be promoting ...
mx
mx
<<Will have to try the SaveAsText ... are you sure about that ? If so, it would render an MDE useless ...>>
Yes. But the code is the kicker. I mean really, how many apps don't have code in them? That's where a lot of the work is.
Forms and reports you could take a screen shot of and duplicate them fairly easily.
Getting all the logic back though is the real trick.
Jim.
Yes. But the code is the kicker. I mean really, how many apps don't have code in them? That's where a lot of the work is.
Forms and reports you could take a screen shot of and duplicate them fairly easily.
Getting all the logic back though is the real trick.
Jim.
"you can get a read-out of the form (sans code) "
Oh ... so, *not* the code, correct ?
mx
Oh ... so, *not* the code, correct ?
mx
@AW,
<<Microsoft strongly advises AGAINST using Macros. The issue is that, as such, macros cannot be 'debugged' - The distinction here is between MACROS and VBA Modules - which contain executable VBA code.>>
Well they've switched again<g>.
Microsoft is now heavily pushing macros once again. There's the new macro designer and they've added error handling (which was the big bug a boo over macros in the past). That's were they also added table triggers.
And with 2010, web databases don't support VBA at all; everything must be done through macros.
Jim.
<<Microsoft strongly advises AGAINST using Macros. The issue is that, as such, macros cannot be 'debugged' - The distinction here is between MACROS and VBA Modules - which contain executable VBA code.>>
Well they've switched again<g>.
Microsoft is now heavily pushing macros once again. There's the new macro designer and they've added error handling (which was the big bug a boo over macros in the past). That's were they also added table triggers.
And with 2010, web databases don't support VBA at all; everything must be done through macros.
Jim.
ok, Bill wins again LOL
@MX
<<"you can get a read-out of the form (sans code) "
Oh ... so, *not* the code, correct ?>>
Not the code, correct. You can get everything else easily enough, just not the code. But as we know, if you have enough knowledge, you can get that as well.
Jim.
<<"you can get a read-out of the form (sans code) "
Oh ... so, *not* the code, correct ?>>
Not the code, correct. You can get everything else easily enough, just not the code. But as we know, if you have enough knowledge, you can get that as well.
Jim.
Have you actually tried that ... SaveAsText / Automation ... from a remote mdb on a target MDE ?
ASKER
question folks - is this part of my thread? no problem, just a little confused
Yes ... just some add on comments and discussion.
mx
mx
ASKER