HUIT

cwilcox and I are colleagues, and this is a followup post for the general public... I have further modified the custom function to be: GetAccountName ( ) Let ([ name = Get ( AccountName ) ; bsPos = Position ( name ; "" ; 1 ; 1 ) ; atPos = Position ( name ; "@" ; 1 ; 1 ) ]; Case ( bsPos > 0 ; Right ( name ; Length ( name ) - bsPos ) ; /* begins with domain name, e.g. "fas_domain" */ atPos > 0 ; Left ( name ; atPos - 1 ) ; /* ends with FQDN, e.g. "@ad.fas.harvard.edu" */ name ) ) The calculated value for the "modified by" field is: Let ( trigger = <insert name of modified field> ; GetAccountName ( ) ) The trigger field above can be any field that, when modified, will trigger the account name update. If a solution requires that the "modified by" field be updated anytime any field in the record is modified, simply make the trigger field a modification timestamp field (which gets updated every time any field in the record does). If anyone prefers cwilcox's original sollution (not shown above: passing modified account and timestamp fields into the function), they should be careful to wrap their fields with GetFieldName ( ) wherever the custom function is called. This way, things dont break if the name of either of the fields has to change down the road.

Ahhh... OK. So what I wrote IS redundant, because all client versions (assuming at least 7 and up) will function correctly with a calc written in version 11 that is using the new names for the old functions (they get re-written/translated/digested/whatever automagically), and calcs written in versions prior to 11 will work fine in 11. This is a "built-in" compatibility of sorts based on the fact that calculation code is stored in terms of function IDs and not human readable code. Do I understand this correctly?

Wait, so a file with a calculation using "Get(CurrentPrivilegeSetName)" in FM11 is not read as "Get(PrivilegeSetName)" when opened/used in FM10? That is what I meant when I said "forward compatibility".

You are absolutely correct. I just wasn't sure how FM10 knew to make the "translation" in a formula that originated in FM11. Was it an update to version 10? We have a mixed environment of clients with versions going back to 8.5 in some rare cases. I figured that this forwards compatibility didn't extend back to versions prior to 10. I may be wrong in this assumption, and may have "recreated the wheel" as you have implied. I haven't had a chance to test my assumption. I guess I'll report back when I do.

I'm not sure I follow. Could you give me a scenario where one would get differing results in differing versions? The definitions of these functions in versions 10 and 11 seem to be almost identical, with no apparent difference (to me) in actuality.

For those who have a really mixed client version environment: GetClientVersion(){ GetAsNumber ( ( RightWords( Get(ApplicationVersion) ; 1 ) ) ) } GetCurrentPrivilegeSetName(){ If ( GetClientVersion() < 11; Evaluate( "Get(PrivilegeSetName)" ); Evaluate( "Get(CurrentPrivilegeSetName)" ) ) } GetCurrentExtendedPrivileges(){ If ( GetClientVersion() < 11; Evaluate( "Get(ExtendedPrivileges)" ); Evaluate( "Get(CurrentExtendedPrivileges)" ) ) } GetActivePortalRowNumber(){ If ( GetClientVersion() < 11; Evaluate( "Get(PortalRowNumber)" ); Evaluate( "Get(ActivePortalRowNumber)" ) ) } I wasn't sure how forwards compatibility would work with versions < 10, so I decided to write the custom functions listed above.

I say try it on one machine first. These patches are so small (~50kb), methinks they just regenerate the certs properly and don't touch the rest of your FM installation. Should be OK. I'm sure FM Inc. tested these patches. They better have... Oh, and... I don't think there's a need to install these if you have a valid cert file that was generated during an install with the system clock set before Sept. 22nd, 2008. If you copied a cert file instead of generating a new one by changing your system date back, I suggest you run the patch. It's generally a bad idea to have the same cert on multiple clients. Although, I don't think it's so bad with FM.

OK. YOU solved the problem and I helped. I'm sure I could have figured it out sooner if I didn't have to rebuild AV's DT and McAfee didn't crap all over our VNC setup on 90 machines. It was a great find though. :clap:

Looking at the date of the original post, I may be off on the exact date this thing should have started. Perhaps it's slightly different for each platform. Anyway, try the solution and see what happens...

See my last post here: http://fmforums.com/forum/showtopic.php?tid/198157/fromactivity/topics/

It is in fact an SSL issue. I fixed the problem by replacing the server.pem SSL certificate file with one from a working system. While this is a full working solution, it comes with a caveat. This will allow you to leave SSL encryption enabled, but having the same cert on multiple client machines is generally a bad idea. On Win: -Replace server.pem at the "Program Files > FileMaker > FileMaker " directory. On Mac: -Replace server.pem at the "Applications > FileMaker > FileMaker .app > Contents > MacOS" directory. Note: A *.app (application) package can be accessed by right/control clicking on it and choosing "Show Package Contents". The bug is caused because the FileMaker installer fails to create a valid certificate file on install. Each cert file contains "not before" and "not after" dates to define the scope of the certificate. The "not before" date is the date of the install. The "not after" date is 863913600 seconds (9,999 days) after the install date. If you add 863913600 seconds to any date after September 22th, 2008, the date is incorrectly interpreted by the installer as a date on or after Jan 1st, 1970. This makes the cert unusable because the "not after" date is in 1970 and 2008 is definitely after 1970. This affects multiple versions of FileMaker. Seems like the cause is not a code change or update. Time just had to pass to make this one happen. The best solution to the problem is to do a reinstall of the application while having your computer's clock set to a date before September 22th, 2008, apply all updates and set the date back to today. The cert that's created should be valid. We have tried to change the date manually, but the encrypted portion of the certificate relies on the original date set. It did not work. Loosely related material: http://www.2038bug.com/ http://en.wikipedia.org/wiki/Year_2038_problem

I now have another machine with the problem. It's running OS X Tiger. I upgraded from FMP 8.5 to 9 and now it's toast. -HUIT

The reason that your desktop shortcuts are opening in FM9 is because the FMP7 network protocol is still associated with FM9. This association happened when you installed FM9. There is no such thing as an FMP9 protocol. The fp7 file extension association is unrelated. To change the association... On Mac: -Download and install "More Internet" (http://www.monkeyfood.com/software/MoreInternet/) -Use it (appears in Mac preferences) to change the association. On Win: -Use the registry editor to edit the key at HKEY_LOCAL_MACHINESOFTWAREClassesFMP7shellopencommand As for your original problem, I have no clue. I have an OS X Leopard machine running FMP 9.0v3 that wont open any databases that are hosted on a non-client version of FM. I get the same error and symptoms as you. It started happening when the FM v3 client update was installed. Unfortunately, uninstalling/reinstalling FM and going back to v1 did not work. Something permanently changed. FM is mission critical for this machine. I'll let you know if I find a solution. -HUIT