Standard Programming Practices?

[evanscamman]

I'm about to start a new project and would like to get your thoughts on a few different issues:

1) Macros vs. VBA

My last project didn't use a single macro (except AutoExec and AutoKeys). With error handling for macros in 2007, is there a case for using them to handle repetitive tasks? For example: Launching a common form on a double-click event. Also, the custom Ribbon examples from MS use macros for callbacks - no VBA. (Is there a good reason for this, or are they just making a point?)

2) Custom UI based on Windows Login.

I understand Access is not "secure". None of my data will be legally sensitive, but I would like user-level access to keep snoopers from minding other people's business or messing up tables, etc... I can make different ribbons and use the Windows Login UserName to match the appropriate UI for each user's level of access. Do you think this is a good approach for my purposes?

3) Storing Input Mask Characters with Field

Is this a good idea for phone numbers, etc? or should I only ever store the raw data.

4) What's normalization?

Haha - just kidding.


Thank you,
Evan

 

[Banana]

1) The reason, as I understand it, for them wanting us to use macros is to help develop a secure application because embedded macros can be "trusted" more than a code snippet that could do *anything* (including deleting all files on your hard drive, for instance). Indeed, I've learned that in 2007 using wizards anything may give you a macro instead of writing code as it did in earlier version.

I also understand that they've fixed up and improved on macros, which I was instantly turned off by a bad experience with a badly-written macros that caused a error that I couldn't work around to delete the macro. That was long ago, when I was very new to Access; if I (as a newbie) can't even get it right, then it's not worth it. Thus, I would need lot of convincing to change my mind.

2) It sounds good, especially if you compile it into MDE/ACCDE. But just so you know- you still can create a new MDB in 2007 and keep all ULS you want. Alternatively, you can use a DIY solution to re-implement ULS. Also be aware that as of now, there is no simple way to change the ribbon; I think we have to use XML to manipulate the ribbon.

3) It depends, unfortunately. The question would be, "Will you ever need to extract bits and parts of the numbers?" and "Will you need to re-format the number into a different representation?" There may be other questions but basically you need to think about what you will do with the numbers to answer that question.

4) It's a process where we make our database efficient by introducing multiple fields of similar definition to maximize the available storage allocation, protecting data's integrity by storing it in multiple locations, and being very descriptive about one entity, using wide tables to encompass all possible attributes.


(Disclaimer for the newbies: the #4 is a joke.)

 

[Simon_MT]

I prefer to use VBA because:

1) On a really basic level, it is self-contained, all VBA can be interrogated using Find.

2) Coming from an Access 1997, the macros were very basic and VBA was a more elegant solution. It is also a good skill to master and more disciplined.

I don't bother with the ribbon and use my own Menu system using Forms. The logic is that as we are already developing Forms why not put the Menu System into one.

Simon