Stored Calculations

[boblarson]

Actually I think Date is worse than Name. I have seen a case where the Date() function refused to keep its brackets, apparently preferring to refer to the field.

I'll disagree because the brackets are only used in queries or control sources, not in VBA and you can get around the Date problem in VBA if you use

VBA.Date

But NAME permeates EVERYTHING.

 

[Galaxiom]

.......the brackets are only used in queries or control sources, not in VBA and you can get around the Date problem in VBA if you use

VBA.Date

So that is what was going on. Thanks Bob.

 

[ChrisO]

Bob.

>>It will honk that up.<<
This is an international site so maybe you could explain the meaning of that.

Regards,
Chris.

 

[RainLover]

PS Next thing you guys will be saying is that you have Never created a Database that uses the word "Name" as one of the fields in a table.

The fact is, is that EVERY MS Access Database has a Field called NAME.

 

[boblarson]

The fact is, is that EVERY MS Access Database has a Field called NAME.

Yes, in MSysObjects - a system table and that is the only one which should have that in it. But there should not be one in any table the DEVELOPER CREATES.

 

[boblarson]

Bob.

>>It will honk that up.<<
This is an international site so maybe you could explain the meaning of that.

Regards,
Chris.

Honk that up means


To F#!k it up,
To Mess it up
To screw it up
To botch

Feel free to add any others.

 

[RainLover]

That is correct Bob.

The point being is that it does exist and it still works.

 

[ChrisO]

Thanks Bob, I think that gets the message across.

 

[SOS]

That is correct Bob.

The point being is that it does exist and it still works.

The point is pointless because it is a SYSTEM table and designed to work with it. Any other use of it is not good. I'm surprised you wouldn't know that RainLover as you seem to have been around a while. Just because a system table has something doesn't mean you can use it in your own tables. In fact, that is probably going to indicate (or should indicate) that you should NOT use it.

I agree with you completely Bob.

 

[Galaxiom]

Honk that up means:

Also in Aussie:

Balls up (though more often used as one would a noun "That was a balls up")
Stuff up

 

[Galaxiom]

The point is pointless because it is a SYSTEM table and designed to work with it. Any other use of it is not good. I'm surprised you wouldn't know that RainLover as you seem to have been around a while. Just because a system table has something doesn't mean you can use it in your own tables. In fact, that is probably going to indicate (or should indicate) that you should NOT use it.

Reusing the fieldname should not be the issue at all. After all we can have tableA.field1 and tableB.field1 without Access getting confused. It just means the tablename and brackets must always be included to disambiguate.

[MSysObjects].[Name] is quite distinguishable from [MyTable].[Name]

The real issue is that MSysObjects.Name holds the value of the Name Property of the database objects. Hence .Name could potentially refer to a field or a property.

Although I can accept there are potential problems, in my minimal experience I am actually yet to see a case where [tablename].[name] with the full brackets and the tablename included causes trouble. I dare say the most experienced here haven't either because they long ago learnt it was not to be done.

An example of code where the use of [tablename].[fieldname] fails would settle the case of it being fact or fiction forever.

Using reserved names does make the code harder to read because Name jumps out as a property rather than a field. It means extra typing for the brackets and intractable bugs if those brackets are inadvertently ommitted.

Besides, why risk it. It is certainly good practice to avoid reserved words.

All the same I would like to see it break for myself.

 

[boblarson]

I've just seen too many posts here where someone used NAME as field name and they were having problems and renaming the field fixed it. Anyway, an interesting thing in 2007 is that if you try to name a field NAME it does tell you that is a reserved word and you shouldn't do it because it can cause problems. So, anyone can do so but it is at their own peril.

 

[ChrisO]

SOS.

I think your post is ambiguous…

>>The point is pointless because it is a SYSTEM table and designed to work with it.<<
If a SYSTEM table can use Name and be used with it by the system (Microsoft) then why can’t a user use the same Name in the same table the same way? Sure, Microsoft may remover the field Name in future versions of Access but they may also remove VBA as well. If we become overly concerned about the future then we couldn’t write anything.

>>Any other use of it is not good.<<
Why? That to me is just a personal opinion but is expressed in a way that purports to be fact. That is the purpose of this thread, trying not to overly read too much into a posting by anyone.

>>I'm surprised you wouldn't know that RainLover as you seem to have been around a while.<<
Know what, your opinion? Why do you think your opinion, as expressed here, has any more weight to it than anyone else in this thread?

>>Just because a system table has something doesn't mean you can use it in your own tables.<<
What does ‘can’ mean, and who suggested it could or should be used in user defined field names?

>>In fact, that is probably going to indicate (or should indicate) that you should NOT use it.<<
Why? If a system table used a perfectly good name would it also indicate we should not use the same perfectly good name? It is an assumption, on your part, that its use is wrong and therefore its wrong use should not be propagated but that propagation has not been suggested.

The line of text by RainLover was this: -
>>PS Next thing you guys will be saying is that you have Never created a Database that uses the word "Name" as one of the fields in a table.<<

Read it again but read it carefully. Nowhere does it say that we should create a field name called ‘Name’. What is says is that we have all created a Database with a Table that has a field name called ‘Name’.

There is a very important distinction here which I am sure RainLover knows all to well but I will point it out.

We can not change the MSysObjects table and re-name that field name to something which we would prefer, that table is read only. Some of us need to work with linked tables which are also read-only. We can not change a read-only table to suite ourselves; we must learn to work with what is provided.

We can not say to our employer, “Oh! That table has a reserved word as a field name and I have been told I must not use reserved words in tables.”

The end logic of that is that we can not change what we are given and we can not work with what we are given, ergo…no work.

But the person, who is out of work, is not a professional because they are not being paid.

So under the circumstances, the person who uses the reserved words as provided, and can’t be changed because they are read only, is the professional because they are still being paid to do so.

 

[namliam]

The point is pointless because it is a SYSTEM table and designed to work with it.

Worse even IMHO, as far as I know, M$ dont support the usage of this table.

Furthermore, M$ themselves in examples propegate stuff the "is bad form" that we all agree too... Simple things like, spaces in column names or special characters, but even more painfull mistakes excist in the examples.
Do we propegate those? No, becuase they are either plain bad, or "good practice" prevents us from doing same.

Same goes for Name or Select or other reserved words, there is ways around everything, but good practice says dont.

 

[ChrisO]

>>Same goes for Name or Select or other reserved words, there is ways around everything, but good practice says dont.<<

Who said do?

 

[Rabbie]

We can not say to our employer, “Oh! That table has a reserved word as a field name and I have been told I must not use reserved words in tables.”

IMHO it's not a question of must not but a question of should not. It will work if you do but it can lead to problems that you will avoid if you don't use reserved words as names. So why make unnecessary grief for the person who has to do the maintenance

But the person, who is out of work, is not a professional because they are not being paid.

So under the circumstances, the person who uses the reserved words as provided, and can’t be changed because they are read only, is the professional because they are still being paid to do so.

A rather unhelpful definition of professional if I may say so.

IMHO Professionalism is an attitude as much as anything else. I dont stop being professional when I do things away from work. Nor do most of the people who contribute to these forums on an unpaid basis.

I am sure we have all seen work done on a paid basis that was not professional in quality etc.

 

[Brianwarnock]

Anybody who does not think that the use of reserved words is crazy is either inexperienced or crazy themselves.

Why run the risk of typos and/or negate the use of Access's help via intellisense, as PatHartman said several years ago we should use all of the help we can get, drag and drop and intellisense should be exploited whereever possible.

Brian

 

[gemma-the-husky]

surely if you COULDNT use a particular word, then access would stop you using it - as it does with illegal characters in control names. but i have certainly used fields called date inadvertently

it stops you using reserved/system words in vba, ok

i am not sure whether you can write a function with the same name as an existing function - it would be an irritation if you could

i try to avoid putting spaces in field names - but from time to time, i import spreadsheets, and the column headers have spaces, so i end up having to use spaces

 

[boblarson]

surely if you COULDNT use a particular word, then access would stop you using it - as it does with illegal characters in control names.

Not necessarily. Remember how hard it is for us to code to keep bad input out from users. It is just as hard to keep programmers from doing bad things and it is, from a cost/benefit perspective, not something Microsoft would probably spend a lot of time on. They have improved upon some of that in 2007 (it warns you not to use date as a date field in the table, but it won't stop you if you really want to do it). It is just like anything - there are things you really should not do if you don't want to get hurt. But some people will push the envelope and exceed or go beyond what is considered safe (rocket cars, base jumping, etc). So, many times they come out unscathed, but it doesn't make doing so any safer. So, people can do just about anything they want to do in Access. Does it make it smart or wise? No, but ultimately it is their choice to do it that counts and all you can do is warn them of the dangers and then sit back and let it go. If they get burned then they might not do it again. If they don't, they just may try it again.

So - whatever floats your boat.

 

[Rabbie]

surely if you COULDNT use a particular word, then access would stop you using it - as it does with illegal characters in control names. but i have certainly used fields called date inadvertently

it stops you using reserved/system words in vba, ok

i am not sure whether you can write a function with the same name as an existing function - it would be an irritation if you could

i try to avoid putting spaces in field names - but from time to time, i import spreadsheets, and the column headers have spaces, so i end up having to use spaces

I think the point here is that you shouldn't use reserved words as data names not that you can't. It nearly always possible to use them successfully but it can cause confusion later on