"Date" as field name

[QuinTech]

Hi all, am i correct in thinking i will run into problems if i have a field whose name is "date"? I seem to remember seeing this somewhere, but i can't find a reference here.

TIA,

Jerry

[-Queue-]

I don't think you should have any problems using 'date'. I think you might want to make it a little more descriptive, though.

[QuinTech]

That's what i told my boss... but he's the boss. Thanks for the reply, Queue, but i miss Yakko now.

J

[-Queue-]

You mean <ahem> Wakko.

[QuinTech]

Sorry, Pooh-bah.

[Lee Smith]

FileMaker will allow you to name a field just about anything you want, well almost anything. So you can name it something as simple as "date". However, using a name like that really doesn't tell you anything about the field, with the possible exception being that it is a date, and even that doesn't have to be true. So, it import to me to be able to look at the field in the future and know what the field is. Instead of date, use something like; Date_Begin, End_Date, Date_Contact, Last_Contact_Date, etc. Also, you should take a look at the Free PDF "Standard.PDF" available from Core Solution and "dwstandard.pdf" available from DataWorks. Both PDFs give you some great ways to name field, files, etc., so that anyone in your organization will know what your field does. Make documentation of your files a lot easier also.

http://www.coresolutions.on.ca/filemaker/standards.php

and

http://www.dataworks.ca/

HTH

Lee

[QuinTech]

Thanks, Lee. I typically agree with you as far as naming conventions go, but this is one case where simply calling this field "date" may be, logically speaking, appropriate, since this date could be one of several things--a date of death, a date of purchase of stock, a date of transfer of a stock or bond, ... or just the date of a transaction. It is, fortunately, the only date that is really relevant for records in this file, and we determine how to use it depending on the contents of other fields, such as the type of security (in the financial sense of that word) or certain other factors. Thus, to name it "Date_Acquired" or anything specific would be a misnomer, since it might actually be the date the holder died, or something completely different. Additionally, creating multiple fields would exponentially increase the difficulty of scripting, and this particular file (one in a solution of almost 50 files) has over 1000 scripts. So identifying the contents of the field by the field's name is not an issue for us.

My concern is this: i have a trace memory of some potential problem that could occur in a calc field definition that references a field named "date". Does this sound familiar to you at all? I fear if you can't help, no one can...

J

[Vaughan]

Regarding field names: if FMP has a problem with the name it'll issue a warning when the field is first defined. It'll still let the field have the problematic name, even if it means it can't be used in a calculation field later on (I've seen a few of these in my time).

[QuinTech]

Thanks, guys. Yinz have put my mind at ease. Don't know where i got this idea from.

J

[MoonShadow]

Quintech said ... Thus, to name it "Date_Acquired" or anything specific would be a misnomer

Oh, I have been in this quandry myself. Part of the concern is that, if used in a calculation, it may not always be clear whether one is referring to a field or a function. Think of Date(Date ... ) complex calculations.

One that seems to work when describing multiple activity dates is ... ActivityDate ... when did something happen and the 'something' is determined by either the file/table or another field or relationship, so its meaning is pretty clear, and you also seem to be able to know the date meaning. This works most times for me.

I have stumbled on using Date and, then later, thought the calculation referred to the Function. Time can be wasted rethinking what the calculation represents and I've made errors.

[Lee Smith]

LOL,

Okay, whatever.

So, I forget now, how many days was it that have elapsed between date and ahhhhhh - date?

No response is necessary,

:

[LaRetta]

Hi QuinTech,

You may be thinking of FM help where it discusses Reserved Names.

Using a reserved word or symbol for a field or table name - FileMaker Pro reserves the use of some words and symbols, including: The names of functions that have no arguments such as Pi or Random. Pre-defined parameters of some functions such as the Roman and Greek font scripts for the TextFont function. Some keywords and symbols...

When you double-click to choose a field for a calculation, FileMaker Pro will automatically wrap the characters ${ } around field names that are reserved words or that contain reserved symbols. Examples:

${A + B} returns the contents of a field named A + B.

${.123} returns the contents of a field named .123.

${Pi} returns the contents of a field named Pi.

There is also another reference I read about but don't recall where - probably in one of the FM7 pdfs but, as Vaughan indicated, you will be told. I have noticed in the NightWing demo for Audit Tracking (for instance), the field name is -- USER DATA -- and it has an auto-enter calculation of: ${-- USER DATA --} but the fields are blank!

I am unsure as to the reason for this calculation but it is wrapped with ${} because '-' is considered reserved.

LaRetta

[QuinTech]

Hmmmm... the ${field} syntax doesn't work for me on FM6... is this new in version 7?

I've really gotta catch up with you guys.

J

[TheDigitalMan]

I am going to throw my two cents worth in here! I tend to agree with MoonShadow. I would NEVER name a field after a FUNCTION name PERIOD!!!

I think it's just asking for trouble. Name it "TheDate" or "ActivityDate" as MoonShadow has suggested or simply "Dt" but I would not name it "Date".

But hey, who am I to say. I'm just a grumpy old programmer from the ole days.

[LaRetta]

Sorry Jerry, I didn't notice your version.

I shy from naming fields the same as functions also simply for myself (or the next person trying to decypher my code). Consider Month, Day, Year etc. Hmmm, Date(Month, Day, Year). Is that a real calculation (with fields) or an example from FileMaker Help? The more complex the calculation, the more this would drive one nuts! But FileMaker keeps it straight.

LaRetta

[Fitch]

Why the hell should your boss care what name you use for a field? You can label it anything you want on a layout, it doesn't have to match the field name, is that what he's worried about?

[QuinTech]

Well, he's the one who created the field, along with the 50-file solution. There are 1500+ fields in this file alone, and many of the other files have more fields. There are hundreds of scripts that use plug-ins like ScriptIt and thus may have the field name in quotes, not as an actual pointer (that's probably not the right word but you get my drift), and thus if i change the field name those scripts will break.

Tom, non-tech bosses who try to meddle in their techs' affairs annoy the hell out of me, too. I used to work under a guy who didn't know the difference between Access and Excel but tried to tell me how to run a database. This is not one of those cases, my boss now is actually somewhat of an FM genius. In retrospect, i probably should have realized that if he gave this field this name, there is almost certainly not an issue with it.

Thanks, all, for the input. I didn't expect this to take off like it did...

J

[-Queue-]

Using lowercase field names could be helpful. It's relatively easy to distinguish date from Date. Also, a function will have an open parenthesis directly following it, so you would have Date( but not date(, at least not once you click OK in a calculation.