View Poll Results: What should I name my Access Controls/SQL Parameters?

6. You may not vote on this poll
  • cboCompany - Access Naming Convention

    2 33.33%
  • chvCompany - SQL Naming Convention

    1 16.67%
  • prmCompany - My Naming Convention

    0 0%
  • Naming Convetions? We don't need no stinkin' naming convention

    2 33.33%
  • I have a better idea that I'll give you below

    1 16.67%
Results 1 to 6 of 6
  1. #1
    Join Date
    Feb 2004

    Unanswered: Naming Conventions - Access vs. VB vs. SQL

    I am really pulling out my hair here. Please help!

    Naming Conventions are Important
    I decided to sit down and spend a few days going through my Access Data Project (2003) renaming the controls and variables following a consistent naming convention because I know it will be worth it in the future as my application grows in complexity. It has already paid off in peace of mind if anything else.

    Consistency is the Key
    The most important thing in any naming convention is CONSISTENCY, not the specific abreviations you end up using. I chose to use The Leszynski/Reddick Guidelines for Microsoft available here: for simplicity. It made sense, and I figured if it was being published on Microsoft's website, chances are it would be applicable in the future.

    Yet Somehow Conflicts Still Arise
    Anyway...I'm trying to be consistent, but it's very hard. For example, Access Data Projects have a kick-!@# feature where if you have a parameterized stored procedure as the recordsource for a form or control, all you have to do is put a control with the name of each parameter on the form and requery the recordsource after any of the parameters are updated. It's GREAT.

    Which "Consistency" should take precedence?
    However...then what do I name my controls and my parameters?

    Do I use the Access naming convention of cboCompany for a combobox and then name the SQL parameter cboCompany? What if I am calling the same stored procedure on another form only I'm using a listbox or a textbox for the user to choose which company to use? I would normally name those controls lstCompany or txtCompany. What do I name the SQL parameter then?

    I could follow SQL Server naming conventions and name the parameter chvCompany because the parameter a varchar datatype. (As per this naming convention But then I have to name all of my controls chvCompany which kinda goes against my typical naming convention for controls.

    I could follow the VB naming convention and just call them both strCompany for a string datatype, but I don't like that idea.

    My Own
    I could just name them prmCompany because it's a parameter and it will be an indication from the Access side that I need to be careful what I name this control because it is a parameter for another control or form's recordsource.

    What do you think?
    Anyway...what do you think, any other suggestions. I think I am just looking for a good reason to choose one over the other and I am too tired to think on my own. Should I name the controls and the parameters following Access or SQL Server naming conventions?

    Please give me your answer and WHY you think one should take precedence over the other. Thank you!
    Last edited by grrr223; 06-22-04 at 20:12.

  2. #2
    Join Date
    Mar 2004
    The most important is consistancy, it makes it much easier to read, maintain and for other developers to read your code. I use a variation of the hungarian notation similar to described in this link in all my programming:

    Download for FREE the ADO/DAO Data Controls that makes life EASIER developing database applications in: VB, FoxPro, Access, VC++, .NET etc... Navigate, Add New, Delete, Update, Search, Undo and Save your changes. Supports Disconnected Recordsets and Transactions!

    Or try our Ask An Expert service to answer any of your questions!

  3. #3
    Join Date
    Jun 2003
    I could follow SQL Server naming conventions and name the parameter chvCompany because the parameter a varchar datatype. (As per this naming convention But then I have to name all of my controls chvCompany which kinda goes against my typical naming convention for controls.

    Yes, that would seem a little odd.

    In general think about if another developer has to finish or maintain your project what would he most likely be most comforable with?
    J. Paul Schmidt, Freelance Web and Database Developer
    Access Database Sample, Web Database Sample, ASP Design Tips

  4. #4
    Join Date
    Feb 2004
    Thank you for your suggestions.

    I know that consistency is important. The problem is that I have more than one "consistency" I'm trying to follow. The issues arise when these two worlds collide as often happens in the wonderful world of Access Data Projects.

    If I were working in Access, I would probably name the control cboCompany because it's usually a combobox. But if I pass that variable from another control, I still then have to remember that the parameter is called cboCompany. That's really the reason that I was considering chvCompany. Because then, no matter what control I am passing the parameter to the stored procedure from, I can at least be consistent in that regard.

    The other reason I am leaning towards chvCompany is that when I have 3 (or 5 or 7) parameters that I am passing, I might end up with cboCompany, txtCustomer, and lstOrderNo, which when I am then trying to reuse that stored procedure (one of the beauties of even creating a stored procedure vs. dynamic sql) there isn't much reason for it.

    Thanks again for your help, I think I was just trying to look at this from a few angles before making a decision that I can live with.

  5. #5
    Join Date
    Mar 2003
    The Bottom of The Barrel
    Provided Answers: 1
    When in Rome...

    Use Access conventions when in Access, SQL when writing scripts etc etc...

    I even get to throw in some Delphi for good measure.

    This works quite well if you take a modular approach to your programming. "Getter/Setter" methods will save your life when it comes to making different platforms play nice with eachother, while maintaining safe, readable, and easily interpreted code by not only you, but other programmers who may be assisting you.

    For instance, when calling a UDF or SP in SQL Server that takes arguments from access, SQL Server could really care less what the name of the Access variable is that's being passed to SQL Server.

    An access combo box has no need for a datatype, why give it one? A object type of the source passing a variable to SQL doesn't matter to SQL Server, why bother?
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  6. #6
    Join Date
    Feb 2004
    For my reports I follow exactly what you are suggesting. I name the SQL parameters following SQL naming conventions and I name the VB variables following VB naming conventions and then build the strings that way.

    However, on forms, ADP's have an awesome [undocumented] feature where you don't need to write any code (other than .requery after updates), all that you have to do is place controls on the form with the same name as the stored procedure's parameters. It's very useful.

    For example, I have a form that has a list of sales as it's recordsource. It takes cboComany as it's parameter. I have a combobox named cboCompany on the form. I just have me.requery in the combobox's AfterUpdate event. The simplicity of it is quite remarkable.

    Also on the form, I have maybe 10 combo boxes to give the user choices to enter data in various fields. And many of these rely on previous choices in other combo boxes, and by naming the parameters and the controls the same thing, again, all I have to do is add .requery in each control/parameter's AfterUpdate event for every procedure that relies on that control.

    Originally, I began using this feature out of simplicity, but after several months of testing it, it is actually remarkably stable. I have a LOT of things going on on some of my forms that all need to stay in sync, and this method has been bulletproof. is for the forms that my question exists because you lose that layer of abstraction. I am really not concerned with this application being compatible with any other apps or systems or platforms or whatever. We will be using Access and SQL Server for a long time.

    Thanks , you always have good ideas Teddy!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts