With all due respect to Stan Leszynski and Greg Reddick, I'm still wondering
how to name controls on forms in my Access MDB.
Correct me if I'm wrong...
If a textbox or other control on a form is *bound* to a table field named
"FullName", then it should *not* be named "txtFullNam e", but rather just
"FullName" - that is, the name of the textbox on a form should always be the
*same as the name of the table field* it's bound to. And because the table
field name should remain independent of its data type there's no need to use
txt, dtm, int or any other prefix.
sound about right?
15  1943 
Unless you are working with a team and must follow team rules, find a system
that suits you.
For me, having the Name and ControlSource the same for bound controls works
fine, but unbound fields get the prefix.
The point of using a different Name from the ControlSource is that you can
then easily distinguish between the Control on the Form and the Field in its
RecordSource. For example, the control has a Visible property, but the Field
does not. The crucial aspect is to be consistent: if you assign a new value
to the Field (named differently than the control), you may not see the new
value in the control until the record is saved (at which point Access
updates the control).
Not many people seem to use prefixes for field names at the table level.
There is some point to it though: Text and Date/Time fields require
delimiters when you embed literals in a SQL string, and this crops up when
building filters for forms, WhereCondtions for OpenReport, the 3rd agument
for DLookup(), etc.
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"deko" <no****@hotmail .com> wrote in message
news:OX******** ***********@new ssvr25.news.pro digy.com... With all due respect to Stan Leszynski and Greg Reddick, I'm still
wondering how to name controls on forms in my Access MDB.
Correct me if I'm wrong...
If a textbox or other control on a form is *bound* to a table field named
"FullName", then it should *not* be named "txtFullNam e", but rather just
"FullName" - that is, the name of the textbox on a form should always be
the *same as the name of the table field* it's bound to. And because the
table field name should remain independent of its data type there's no need to
use txt, dtm, int or any other prefix.
sound about right?
> The point of using a different Name from the ControlSource is that you can then easily distinguish between the Control on the Form and the Field in
its RecordSource. For example, the control has a Visible property, but the
Field does not. The crucial aspect is to be consistent: if you assign a new
value to the Field (named differently than the control), you may not see the new
value in the control until the record is saved (at which point Access
updates the control).
Exactly the insight I was looking for - now I think I know why I had to
resort to DoCmd.RunComman d acCmdSaveRecord in some cases.
Thanks.
> Not many people seem to use prefixes for field names at the table level. There is some point to it though: Text and Date/Time fields require
delimiters when you embed literals in a SQL string, and this crops up when
building filters for forms, WhereCondtions for OpenReport, the 3rd agument
for DLookup(), etc.
A somewhat related question -
I understand that Date/Time fields require delimiters when used in an SQL
string. But what happens when the table field is formatted as "General
Date" (where the field includes the time), and I embed a literal in an SQL
string like #5/17/04# - will this cause problems because there is no time
in the literal?
In general, is it better to format table fields, or simply leave the table
format properly blank? I've formatted many of the textboxes in my forms as
date/time - should the format of the textbox match that of the table? does
it matter?
thanks again...
The Format property of the field in the table affects only how Access
displays the data. Internally, it stores it as a fractional number, where
the integer part represents the date, and the time the time of day (0.5 =
noon, 0.25 = 6am (quarter day), etc.)
Literals in a SQL statement should be entered as mm/dd/yyyy, regardless of
the user's local settings or the display formats requested.
If the date field in the table does have a time component (other than
midnight), it will not match the literal date unless the times are exactly
the same. To retrieve all records dated any time on May 17, use:
([MyDate] >= #5/17/2004#) AND ([MyDate] < #5/18/2004#)
If you are using Access in a country that uses a non-US date format, see:
International Date Formats in Access
at: http://allenbrowne.com/ser-36.html
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"deko" <no****@hotmail .com> wrote in message
news:rn******** ***********@new ssvr25.news.pro digy.com... Not many people seem to use prefixes for field names at the table level.
There is some point to it though: Text and Date/Time fields require
delimiters when you embed literals in a SQL string, and this crops up
when building filters for forms, WhereCondtions for OpenReport, the 3rd
agument for DLookup(), etc.
A somewhat related question -
I understand that Date/Time fields require delimiters when used in an SQL
string. But what happens when the table field is formatted as "General
Date" (where the field includes the time), and I embed a literal in an SQL
string like #5/17/04# - will this cause problems because there is no time
in the literal?
In general, is it better to format table fields, or simply leave the table
format properly blank? I've formatted many of the textboxes in my forms
as date/time - should the format of the textbox match that of the table?
does it matter?
thanks again...
After all the discussion between Allen and yourself, a recommendation that goes
back to the beginning when you are first designing your tables is to avoid using
the same field name in more than one table. This avoids the problem of having
two tables in a query with one or more duplicate field names and Access raising
the message that it can not determine which table is being referenced when a
duplicate field name is included in the query grid.
--
PC Datasheet
Your Resource For Help With Access, Excel And Word Applications re******@pcdata sheet.com www.pcdatasheet.com
"deko" <no****@hotmail .com> wrote in message
news:OX******** ***********@new ssvr25.news.pro digy.com... With all due respect to Stan Leszynski and Greg Reddick, I'm still wondering
how to name controls on forms in my Access MDB.
Correct me if I'm wrong...
If a textbox or other control on a form is *bound* to a table field named
"FullName", then it should *not* be named "txtFullNam e", but rather just
"FullName" - that is, the name of the textbox on a form should always be the
*same as the name of the table field* it's bound to. And because the table
field name should remain independent of its data type there's no need to use
txt, dtm, int or any other prefix.
sound about right?
In that case disambiguate with the table name or alias the table and
disambiguate with the alias.
--
Terry Kreft
MVP Microsoft Access
"PC Datasheet" <sp**@nospam.sp am> wrote in message
news:yU******** **********@news read2.news.atl. earthlink.net.. . After all the discussion between Allen and yourself, a recommendation that
goes back to the beginning when you are first designing your tables is to avoid
using the same field name in more than one table. This avoids the problem of
having two tables in a query with one or more duplicate field names and Access
raising the message that it can not determine which table is being referenced when
a duplicate field name is included in the query grid.
--
PC Datasheet
Your Resource For Help With Access, Excel And Word Applications
re******@pcdata sheet.com
www.pcdatasheet.com
"deko" <no****@hotmail .com> wrote in message
news:OX******** ***********@new ssvr25.news.pro digy.com... With all due respect to Stan Leszynski and Greg Reddick, I'm still
wondering how to name controls on forms in my Access MDB.
Correct me if I'm wrong...
If a textbox or other control on a form is *bound* to a table field
named "FullName", then it should *not* be named "txtFullNam e", but rather just
"FullName" - that is, the name of the textbox on a form should always be
the *same as the name of the table field* it's bound to. And because the
table field name should remain independent of its data type there's no need to
use txt, dtm, int or any other prefix.
sound about right?
Yes, that's what you have to do when there are duplicate field names. My point
is that you can avoid this in the first place with some forethought.
Steve
PC Datasheet
"Terry Kreft" <te*********@mp s.co.uk> wrote in message
news:Yo******** ************@ka roo.co.uk... In that case disambiguate with the table name or alias the table and
disambiguate with the alias.
--
Terry Kreft
MVP Microsoft Access
"PC Datasheet" <sp**@nospam.sp am> wrote in message
news:yU******** **********@news read2.news.atl. earthlink.net.. . After all the discussion between Allen and yourself, a recommendation that
goes back to the beginning when you are first designing your tables is to avoid
using the same field name in more than one table. This avoids the problem of
having two tables in a query with one or more duplicate field names and Access
raising the message that it can not determine which table is being referenced when
a duplicate field name is included in the query grid.
--
PC Datasheet
Your Resource For Help With Access, Excel And Word Applications
re******@pcdata sheet.com
www.pcdatasheet.com
"deko" <no****@hotmail .com> wrote in message
news:OX******** ***********@new ssvr25.news.pro digy.com... With all due respect to Stan Leszynski and Greg Reddick, I'm still wondering how to name controls on forms in my Access MDB.
Correct me if I'm wrong...
If a textbox or other control on a form is *bound* to a table field named "FullName", then it should *not* be named "txtFullNam e", but rather just
"FullName" - that is, the name of the textbox on a form should always be the *same as the name of the table field* it's bound to. And because the table field name should remain independent of its data type there's no need to use txt, dtm, int or any other prefix.
sound about right?
"PC Datasheet" <sp**@nospam.sp am> wrote in
news:yi******** ***********@new sread2.news.atl .earthlink.net: Yes, that's what you have to do when there are duplicate field
names. My point is that you can avoid this in the first place with
some forethought.
If the fields represent the same data, they should arguably have the
same name.
Thus, to me, it seems obvious that foreign keys should have the same
name as the field they are linked to. And, of course, it generally
doesn't cause a problem with queries because you generally don't
*need* both of them in your SELECT.
I also use the same field names for my time stamp fields, Created,
Updated and UpdatedBy. These are generally not relevant to my
queries, and are only used in my forms (for display), where I only
seldom have more than one table in a resultset (I have occasionally
used a 1:1 structure where I had two tables in the recordset for the
form -- in that case, it makes logical sense to give different names
to the time stamp fields in each table).
Having the same names in all the tables makes it very, very easy to
work with those fields, and there's little need for using those
fields in SQL, as they are audit fields and aren't going to come
into play in most joins.
Another point: if you're contemplating using the same names for
fields in different tables, this may be a clue that you have a
normalization problem, especially if there's more than one such
field. The exception would be groups of fields that have functions
that are not related to the data but to the operation of the data
structure (as with my time stamp fields).
I don't avoid name collisions myself, and just don't see problems
with it.
Indeed, the place where I *do* encounter the problem a lot is when
I'm doing self-joins, which in my current project I'm doing a lot
of. And there's no way to get around the name collisions in that
case.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
> If you are using Access in a country that uses a non-US date format, see: International Date Formats in Access
proudly using US date format.
If the date field in the table does have a time component (other than
midnight), it will not match the literal date unless the times are exactly
the same. To retrieve all records dated any time on May 17, use:
([MyDate] >= #5/17/2004#) AND ([MyDate] < #5/18/2004#)
Now that's interesting. I like to time-stamp the modification date
of database records by setting the default value of the "Modified"
table field to Now(). The "Modified" value can then be used
in a query to search for records based on modification date.
So if Record "A" is created on 05/05/04 at 6:00 pm, and I search
for all records BETWEEN #05/05/04 And #05/15/04#, then I assume that Record
A *will* be in the query results because a default time of 12:00 AM is given
to the literals. I was thinking perhaps I needed to set the format property
on the table field to "Short Date" in cases like this, but as you say this
would have no effect since, internally, the dates are stored with a time
value.
Another scenario could be searching for records modified in the last X days,
e.g. "If Modified > (#05/15/2004# - 10)". If this is run at 6:00 pm, and we
are sticklers for precision, we will get false positives if records are
created in the morning hours of 05/10/2004. Is this correct? This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Derek |
last post by:
The company where I work uses a naming convention that I have
never used before. They use mixed-case letters for public
member functions, but lower-case with underscores for the
rest, like this:
class Foo
{
public:
void somePublicMemberFunction();
protected:
|
by: cmiddlebrook |
last post by:
Hi there,
I keep finding myself getting inconsistent with naming conventions for
things like member variables, class names etc and I just want to find
something that suits me and stick to it. I am wondering if there are
any naming conventions around that are deemed suitable by the general
C++ community. I have googled around and I can't find much - mostly
long lists of hungarian-like prefixes which is not really what I'm
after.
|
by: Mark Broadbent |
last post by:
stupid question time again to most of you experts but this is something that
continually bothers me.
I am trying to get into the habit of naming variables and controls in an
assembly as per convensions. The thing is that Ive never really get the full
reference to check against.
Ive seen a couple of articles, but there always seems to be a bit missing. I
also always seem to run into conflicting convensions both in code samples
themselves...
|
by: 42 |
last post by:
Hi,
Stupid question:
I keep bumping into the desire to create classes and properties with the
same name and the current favored naming conventions aren't
automatically differentiating them... (both are "Pascal Case" with no
leading or trailing qualifiers).
For example... I'll be modelling something, e.g. a computer, and I'll
|
by: Carl Colijn |
last post by:
Hi all,
Disclaimer: before I might trigger your "let's start a holy war!" button,
I'd like to say I'm not intended to; I just post this message to get some
input and not to promote "Yet Another Naming Convention". It's a bit of a
long post, but I've spent the past few days on perfecting this, finally came
to the conclusion that maybe I went a bit overboard with it, almost willing
to just say "the @#$ with it" but I didn't want to let it...
| | |
by: jjkboswell |
last post by:
I'm trying to pin down a good naming convention for the 3 things
required to implement an event.
You need:
1) a delegate
2) an event
3) an event handler
Below is my understanding of a naming convention based on the Windows
Forms events. Can someone let me know if this convention is standard,
|
by: MP |
last post by:
Hi,
Coming from a vb6 background I am accustomed to prefixing variable names to
indicate their usage.
Now just beginning to try to learn database stuff I've been lurking here and
working on my first database design.
I was noticing that I never see peoples posts here containing prefixed
object identifiers
If I had a table to contain job records I thought I'd name it tblJobs
|
by: dm1608 |
last post by:
I'm relatively new to ASP.NET 2.0 and am struggling with trying to find the
best naming convention for the BAL and DAL objects within my database. Does
anyone have any recommendations or best practices for naming my objects?
I currently have all my type classses simply called "JobSummaryClass" or
"JobDetailsClass". These classes simply contain the public properties and
the get/set functions for the object. Is this an appropriate naming...
|
by: Jonathan Wood |
last post by:
I was just wondering what naming convention most of you use for class
variables.
Underscore, "m_" prefix, camel case, capitalized, etc?
Has one style emerged as the most popular?
Thanks for any comments.
--
|
by: Smithers |
last post by:
Is it common practise to begin the name of form classes with "frm" (e.g.,
frmOneForm, frmAnotherForm).
Or is that generally considered an outdated convention?
If not "frm" what is a common or recommended practise?
Thanks.
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
| | |
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
