In Access terms, yes, But in the more generic terms within the user world, a field is pretty much anything they see on their screen that contains a data point, data element (etc etc).
I'm all about the interesting (and sometimes frustrating) bridge between the developer and his/her clients
You're misunderstanding the general point I'm making.
Calling a Column a Field makes no sense at all IMO, for several reasons:
It's not a field, it's a column
RDBMS professionals (non-Access) call it a Column
Field is too broad, field can mean any device, real or imaginary, that contains just about anything
Field is usually used by non-tech users to refer to anything they see on the screen
I do support always referring to an Access control as a Control when you are in a tech-on-tech discussion, yes.
I wouldn't say "I'm drawing a new field on my form called cboSomething", I would use "control".
On the other hand, I would never tell a user "Let's add a Control to the screen" - I would say "Let's add a Field to the screen".
Field has a very wide set of implications and usage, depending on the context of the conversation.
However, to me, when in a tech-on-tech discussion, only Column is correct. And yes, I agree, only Control is correct.
So I guess maybe my original comments did not properly acknowledge the various nuances I am now writing.
Isaac, I will merely point out that in Access, that thing we are talking about is defined by something called a Fielddef, so I'm going to call it a Field just out of cantankerousness and pure, plain obstinacy.
When I was in a cubicle next door to our resident C#.net developer, I remember him showing me some stuff and seeing a heck of a lot of them, whatever they are
Well hello again, @Galaxiom. I would disagree with you on that - there is a translation of sorts that has always been needed between the business and the tech groups. In my experience, I can take the rather petty approach of demanding that end-users speak my language, or I can accept that will never happen and meet them where they are at. In an entire lifetime in the adult working world, in the USA at least, at the companies I have worked at, many of which had massive projects going at any given time, the typical users, business analysts, project managers, and corporate project sponsors insisted on using "fields on a screen". Thus, I adapted to their way of thinking while meeting with them and developing requirements.
I do not try to talk 100% tech with an end user.
Do you?
Actually, don't bother to respond to that. I sense you do not wish the same conciliatory end to this matter as I, and am quite finished with this argument, as was made plain on the other thread.
I wish you a more relaxed, pleasant and productive remaining week,
Isaac
I'm talking about the basic structure of the database. It is true that a DAO recordset has a "Fields" collection, but the table has that collection even when it is not the target of an explicit DAO Recordset. In fact, the DAO recordset probably copies/references/otherwise gets it from the TableDef.
Having now looked it up, this is what the standards document says. (Taken from: ANSI/ISO/IEC International Standard (IS) Database Language SQL—Part 2: Foundation (SQL/Foundation) - 1999.)
From paragraph 4.15 (Columns, fields, and attributes)
"The terms column, field, and attribute refer to structural components of tables, row types, and structured types, respectively, in analogous fashion. As the structure of a table consists of one or more columns, so does the structure of a row type consist of one or more fields and that of a structured type one or more attributes."
According to another part of this same standards document, it is permissible to use the word "field" in conjunction with the conventional elements of a date/time value, such as "hours field" or "days field" - since they allow "sub-fields" to be defined and a sub-field is also a field.
Also from that standards document: "A row type is a sequence of (<field name> <data type>) pairs, called fields. It is described by a row type descriptor. A row type descriptor consists of the field descriptor of every field of the row type."
Therefore, there is some basic agreement in the SQL standards document that the term "Column" can indeed apply to something that, once you reach the individual row level, becomes a "Field." This DOES NOT single out DAO in this context.
Common usage in Access always calls that "thing" a field to avoid confusion with the nomenclature of Excel, to which nearly EVERYTHING is a book/sheet/row/column situation. Recall our previous discussion that if all you have is a hammer, everything looks like a nail. Well, if all you have is Excel, everything looks like rows and columns.
Common usage in Access always calls that "thing" a field to avoid confusion with the nomenclature of Excel, to which nearly EVERYTHING is a book/sheet/row/column situation.
I work in Access, SQL Server and Universe so I need to use all these terms and a lot of others. Little wonder I am pedantic about nomenclature.
Universe is a non-1NF database having "attributes" with "multivalues" which can have "subvalues". Its native language (TCL) uses a "sentence" in the structure:
Code:
LIST tablename attribute1 attribute2 WITH attribute3 = whatever
String delimiters are optional if there is no ambiguity. And yes, no commas.
Tables are actually "files" with a "VOCabulary" entry that presents it as table name.
Technically the attributes for TCL are F1 F2 F3 etc (defined by system level descriptors) but a "Dictionary" of descriptors defines alternative names and formats as well as "Associations" between the multivalues of attributes that act like a Relationship between multivalue attributes. The descriptor defines if the output is single or multivalue. Without a descriptor, all values are text.
An "I" descriptor can do complex manipulations on the values and lookups from other tables. A descriptor can call a UNIVERSE BASIC subroutine (function). Generally I-descriptors are used to do most of the complex work.
I-descriptors can Raise or Lower a value, multivalue or subvalue to the next level, eg raising a subvalue to present it as a multivalue or top level value.
There are also descriptors for Verb (keyword definitions), Adverb, Phrase, Sentence and Paragraph.
Dynamic descriptors can also be EVALuated inline and the format of the values and their layout in the results altered. Associations can be defined inline.
A sentence can be written USING a different dictionary.
This sentence will create a "Select List" that applies to subsequent LIST command.
Code:
SELECT tablename attribute1 attribute2 WITH attribute3 = whatever
It also supports a flavour of SQL with "dynamic normalization" that brings out the multivalues as "virtual tables". Only Dictionary descriptors are supported in SQL but all the inline TCL functionality is also supported.
Depending on how it is being addressed, the query criteria key words are WHERE and WHEN. Both WHERE and WHEN are used in the same query. WHERE refers to the whole set of multivalues while WHEN refers to individual multivalues within the WHERE criteria.
"Select Lists" can be written to and applied to SQL.
Code:
SELECT descriptor1, descriptor2 TO SLIST 'listname' FROM tablename
Code:
SELECT attribute1, atribute2 FROM tablename SLIST 'listname'
A table can UNNEST on a multivalue or Association to repeat the single values presenting all the multivalues as full records.
The table to column separators are dots. The table to dynamically normalized table separator is an underscore. Meanwhile identifiers (tablenames and attribute/column descriptors) can include both underscores and dots without the need for delimiters. They are also case sensitive.
The ODBC interface converts all dots in identifiers to underscores.
So next time you are thinking Access or T-SQL syntax is complicated, spare me a thought.
At first I assumed this was some difference in British vs American English. As we know these Brits here do not always speak properly and have some very silly language differences (lifts, and the Tube, and Chips for French Fries). So I checked your profile, and clearly you are not British.
In my experience only time it is referred to as a column is in display but in database design its a field. And it is the non db people, who work in Excel that are the ones calling everything a column.
I personally would never say I join two columns together, or call it a Primary and Foreign column, or it is a required column, etc.
