Omega questions

[LaRetta]

Option-Z on MacBook Pro (Mavericks) gives me Ω

 

I find it interesting that:

• It sorts after all alpha, making it handy in place of prefix of zzzz etc
• It is allowed in field names without FM raising a fuss or wrapping with ${}
• When used in calculations, they all evaluate properly
• When used as table occurrence name it seems to work fine
• It is counted as a word and not as a word separator between text or numbers

It is one of only a few characters I can find which sorts after alpha characters (Options P and M being others).  I know Omega is used in many disciplines from astronomy to mathematics but I believe that FM considers it only a character.

 

Many developers try to move things to the end using z_ but then zip code ends up below so they instead have to use zz.  I think it is a cool character but is it unsafe to use this way?  Is it considered lower ascii?  Would it cause problems in data-exchange or connection with MySQL, Oracle or others?

[jbante]

I like where you're going with this. Another nice thing about Ω is that it's the Greek equivalent of Z, so the meaning is preserved. (Using it to coerce fields to the bottom of an alphabetically sorted list would also be consistent with one of its meanings in math.) Ω is not part of ASCII, but FileMaker doesn't care much as long as it's part of Unicode. (Well, most parts of Unicode, anyway.) I can't speak to how other data-handling tools might deal with it.

[comment]

It sorts after all alpha

 

A small correction: it does not sort after all alpha. It is an alpha (as opposed to numeric or punctuation) character. It's just higher in sort order than all ASCII or Latin characters, since it's part of the Greek alphabet. There are alphabets that are even higher, e.g. Cyrillic that comes immediately after Greek.

 

Of course, this refers to the sort order when the default language selected for the field is English (or Default or Unicode). Other languages may have different rules.

 

 

It is one of only a few characters I can find which sorts after alpha characters (Options P and M being others).

As you can understand from the above, there are thousands of such characters. The advantage of Ω is that it can be easily typed using an English keyboard.

 

 

Would it cause problems in data-exchange

 

In theory, it shouldn't - but there all kinds of legacy systems out there that might choke on it.

[LaRetta]

There is small hesitation still since I was recently bitten with webdings (as you both are aware) but I've had a personal dislike for using the z_ or zz to move developer items to the end so I am sorely tempted to take advantage of it.

 

Yes, Michael, I was looking for something which would sort after 'alpha' (thank you for the clarification) but with standard keyboard so that was all I tested.  You have also expanded my understanding of alternate characters and that is always great fodder!!  Omega is simply such a cool-looking character.  So now, do I risk it?  The good thing is that I never hard-code table or field names so if I had to change them later, it would be no big deal (as far as I can tell).

 

Thank you both for responding - I really appreciate it.  

[comment]

 So now, do I risk it?

 

I think you need to analyze the risk case-by-case. Using it inside calculation fields that never get exported poses no risk whatsoever. Field names? If they are accessed through ODBC, or exported (e.g. using the merge format), then some testing against the third-party application might be in order. But if the initial tests work out fine, then this is very unlikely to become a problem later on, since the world is generally moving forward, not backward (sadly, in matters of technology only).

[LaRetta]

Good morning, Michael!  

 

I just realised that ExecuteSQL() does not like it so it would need to be escaped out similar to:

ExecuteSQL ("
SELECT "Ω"
FROM table " ;
"" ; "" )

But I dislike the clutter of escaping out and I never hard-code table/fields anyway so it makes no difference to me.  Instead for simplicity and to protect from changing field or table names, I always wrap with Kevin Frank's custom functions so it would look like:

ExecuteSQL (
"SELECT " & GFN ( table::Ω ) &
"FROM " & GTN ( table::Ω ) ;
"" ; "" )

I would refer to Kevin's custom functions but Brian Dunning's site keeps saying too many connections, FMFunctions doesn't list them, and Kevin's website FileMakerhacks doesn't list them when I search so I'll post them again here because I dislike referencing something without providing the background as well:

/*    GFN [for GetFieldName] returns only the name of the field, without the relationship portion, as opposed to GetFieldName() which also returns the relationship. This is to be used in SQL queries to protect the field references from breaking if the field is renamed.  The Quote() function "escapes" problematical characters and SQL reserved words, if any -- otherwise, no harm done.   */

Let ( [ 
a = GetFieldName ( field ) ; 
b = Substitute ( a ; "::" ; ¶ ) 
] ; 
Quote ( GetValue ( b ; 2 ) )
) 
// From Kevin Frank

/*   GTN [for GetTableName] returns only the name of the relationship, i.e., the table occurrence (TO) name, as opposed to GetFieldName() which returns the relationship + the field name. This is to be used in SQL queries to protect the TO references from breaking if the TO is renamed.  The Quote() function "escapes" problematical characters and SQL reserved words, if any -- otherwise, no harm done.   
*/

Let ( [ 
a = GetFieldName ( field ) ; 
b = Substitute ( a ; "::" ; ¶ ) 
] ; 
Quote ( GetValue ( b ; 1 ) )
)
// From Kevin Frank

In all, I really like Omega and with your additional input, I shall include it in my toolkit but I will post back if I find anywhere else it might cause a problem.  It is nice to have a character which easily sorts to the end and we can not have too many tools in our toolkits!  Thank you again!

[comment]

You should always quote field names in an SQL query anyway (manually or automatically, it doesn't matter)  because it's easy to get tripped by an SQL reserved name. I would be more worried about outside application accessing the data, since they may not be that smart.