Table name recommendation

[sknightstar]

Hello...
In the A5V8 documentation, I find the following:
"Table and Field Names
Alpha Five recommends that table names, field names, and paths to your files start with a letter (A-Z or a-z) and be composed of letters, numbers (0-9), and underscore (_) characters."

I am now in the process of "converting" all my FMpro databases to A5V8. Because of one client's requirements to save a copy of their table's data at a particular point, I have been in the habit of naming tables beginning with the date in numerals, i.e., "20080202tablename". From the above info, this might cause problems, although I cannot determine why this naming format would do so. I always put the date first because it sorts the tables by date within a folder.

Having thought about table naming since yesterday afternoon, I have come up with the following solution if the above naming convention might cause problems for me:
Given:
1. The 2000 series of years will be around longer than I will.
2. The first 26 years of the 2000 series of years will be around longer
than my business will, and possibly, longer than I will.
New date convention:
1st character: A-Z, beginning with 2001=A.
Therefore 2008=H, 2009=I, ..., 2026=Z
2nd character: 1=Jan, 2=Feb, ..., 9=Sep, A=Oct, B=Nov, C=Dec
3rd and 4th characters: 01=1, 02=2, .... 30=30, 31=31 (day of the month)

Actually, I like the above as the date can be specified in 4 characters.

It looks like I have answered my own question; but, if I have missed something, please let me know.
Thanks,
Steve

[MikeC]

Re: Table name recommendation

Or you could take and separate the dates from the table names (if consistantly named) and place them ALL in the same table. This could then simple be filtered by whatever you want...generally I think this is what most would have in an Alpha DB at least, as is very easy to filter (view) whatever data is wanted and yet have all the information right at hand without "umpteen" tables to deal with.

Just a thought...your way would certainly work too.

[Peter.Greulich]

Re: Table name recommendation

Or you could use a single character followed by your convention:

X20080202tablename
X20080517tablename
etc.

or an underscore:

_20080202tablename
_20080517tablename
etc.

[MikeC]

Re: Table name recommendation

Peter,

I have seen this before in that some people start names with an underscore but according to the naming recommendations of Alpha, names should start with a letter and starting with an underscore would be analogous to starting with a number (which is fairly well known to cause problems).

Any thoughts??

[Stan Mathews]

Re: Table name recommendation

If you crosstab a table and group by columns on a numeric field, Alpha will place an underscore before each numeric value which becomes a field name.

Probably not the best choice to name a field with a leading underscore but apparently at least "legal"/

[MikeC]

Re: Table name recommendation

Thanks Stan. So it seems that Alpha, in this case, goes against its own documentation! I will find it in the help file and submit this as a possible revision using the "Comment" . I guess that is the reason why I posted in the first place...to find out what the inconsistancy was, not realizing that even Alpha used beginning underscores.

:)

[Peter.Greulich]

Re: Table name recommendation

Any thoughts??

Mike,

In addition to what Stan said, I think the problem is beginning names w. numbers. I believe underscores are generally safe. These days, I use underscores as the 1st character of set names. That way I get a clean sort between tables & sets.

[MikeC]

Re: Table name recommendation

Thanks Peter,

I just added to the requested amendments to the documentation via the "Comment" hotspot to basically say what has been said in this thread--that apparently users (and Alpha) use the underscore as the lead character in naming and the documentation should reflect this.

I just checked and so far none of my "suggestions / corrections" have been implemented as of yet for the documentation...at least 5 Comments made so far, two of which got a confirmation reply from Alpha about 5-6 months ago. (noone at Alpha to do it I guess! :( )


EDIT:

:D @ Peter!
|
|
\/
.
.

[Peter.Greulich]

Re: Table name recommendation

(no one at Alpha to do it I guess! :( )

Yeah, a technical writer shortage it would seem. Maybe that will get back to normal after the writer's strike ends.

[sknightstar]

Re: Table name recommendation

Uh, oh. I just noticed I am still using hyphens in my table names.
I have been doing this for so many, many years, it's become a habit and I don't even think about it.
I have used a hyphen in many of my newly "converted" tables.
Although A5V8's documentation does not specifically recommend using a hyphen in a table name, it seems to be OK, so far.
Am I going to run into a problem, in the future, because of using a hyphen in a table name?
Thank you,
Steve

[Peter.Greulich]

Re: Table name recommendation

Am I going to run into a problem, in the future, because of using a hyphen in a table name?

I have lots of old tables w. spaces in the names and even one or two w. hyphens. They seem to work ok. But if you're rebuilding stuff, I would suggest not to use hyphens or spaces.

A long time ago, I had a hyphen in my path folder name, and Alpha sure didn't like that. Not sure if that's still a problem these days.

[Stan Mathews]

Re: Table name recommendation

Uh, oh. I just noticed I am still using hyphens in my table names.
I have been doing this for so many, many years, it's become a habit and I don't even think about it.
I have used a hyphen in many of my newly "converted" tables.
Although A5V8's documentation does not specifically recommend using a hyphen in a table name, it seems to be OK, so far.
Am I going to run into a problem, in the future, because of using a hyphen in a table name?
Thank you,
Steve

I would think that you will run into a problem and it will be a devil of an issue to resolve. Much of Alpha is written in xbasic and xdialog. I have helped others diagnose issues where the underlying xbasic for an operation failed because Alpha was interpreting a table name, containing a hyphen, as a statement subtracting two variables. If I remember correctly it was an append operation.

As ever, my memory is faulty. It was an append operation but it was a space in the table name.

I think the same logic applies. If it doesn't confrom to the published specification, don't do it.

[sknightstar]

Re: Table name recommendation

I think the same logic applies. If it doesn't confrom to the published specification, don't do it.

Ratz. Since I started with DOS, I just will not use spaces in path, directory, folder, file, document, table, field, etc names. I also have a personal bias against using Underscores because they look like spaces.
Well, it�s time to move along, abide by the (A5V8) rules, and get rid of the Hyphens I have in my table, browse, and report names.

Thank you, Stan, for pointing out where I could run into �Hyphen� problems.
Steve

[csda1]

Re: Table name recommendation

I've never seen any problems with underscores, but hyphens and spaces are bad for Alpha as well as others.

Also, don't use fieldnames or index names greater than 10 characters. Once they go over 10, they are stored in an incompatible to a Dbase IV standard that means the data is harder to resurrect when you have corruptions (which occasionally have been know to happen to some)


My biggest concern is using pointers like pointer.and.subpointer be interpreted as an .and. of two values rather than a long pointer. So don't use .AND.,.OR.,.NOT.,.XOR. as a pointer. Similarly, be careful of multiply * near a function that starts with an * (occasionally used by Alpha). In that case, make sure there is a space or parenthesis between the *s.

[sknightstar]

Re: Table name recommendation

Also, don't use fieldnames or index names greater than 10 characters. Once they go over 10, they are stored in an incompatible to a Dbase IV standard that means the data is harder to resurrect when you have corruptions.

UH, OH... That brings up an important, to me, question:
If I already have a field whose name is more than ten characters, it's stored in the incompatible standard. If I then re-structure the table to make the field name 10 characters, is it still stored in the incompatible structure? If it is, is there a way to correct the situation?
Thank you, Ira.
Steve