Open the Preferences dialog, switch to the Server pane
If Panorama X Server is running, stop it
Start Panorama X Server. It will automatically update before launching.
This version takes a detour from bug fixes and adds a major new feature, the join statement. This wasn’t really on the road map even ten days ago, but I had an epiphany about how to do this, and here it is. This new feature gives Panorama X the capability of doing joins in a manner very similar to SQL, including both inner and outer joins.
Used in it’s most basic form, the join statement can perform the same function as a formulafill statement combined with a lookup( function. However, the join statement is much, much faster. In tests joining a 400 record database with a 20,000 record database, join was 5x faster. When joining two 20,000 record databases, join was 135 times faster – a 7 minute formulafill took only 3 seconds with join. I believe these performance gains will increase even further with larger databases.
Of course the join statement isn’t just faster than previous Panorama relational features, it is far more flexible, and makes it much easier to set up comprehensive database joins.
Now that Panorama has join capabilities I have definite further ideas for embedding relational capabilities deeper into the program. However, these ideas may need to wait for a future release.
In addition to the new join feature, Panorama X 10.2b10 also includes nearly a dozen bug fixes and minor new features:
The new GlobalDictionaryBuild statement builds a global dictionary by scanning a database. (This statement was the inspiration for the join statement).
The GetTextDialog statement now works for editing local variables, even when the “sheet” option is used.
The OpenForm statement has a new option, NoVersionButton, that allows you to remove the caret icon just the the right of the window title (at the top of the window), and removes the ability to click on the title to rename the document, or to Command-Click on the title to see the path to this document. This option is now used on all wizard and utility windows (About Panorama, Memory Usage, Formula Workshop, etc.).
The new ClearGlobalDictionaryValues statement clears all values from a global dictionary (without actually deleting the global dictionary).
An .Initialize procedure that closes the database it is associated with no longer causes an error to occur.
Fixed synchronization of secret databases when opened as an auxiliary database and the primary database is not shared.
The OpenAsyncProgressWindow statement no longer fails with an error if passed a window height less than 200 points.
When Panorama is launched by double clicking on the app, the menus now work correctly.
The Server Administration window can no longer be resized (which just showed a bunch of empty white space).
Improved code for updating menus when user role is changed (from admin to user, etc.)
Incorporated documentation corrections submitted by Michael Kellock, Thomas Cooper and Kurt Meyer.
Congratulations! Join is a great new feature, and I immediately tried to implement it in one of my daily use databases.
I had one problem with a field name containing a German special character:
The join statement should import data into a field “Adresse” (address) from a Members database where the corresponding field was named “Straße” (street). This import did not work. I tried to add chevrons around the field name {«Straße»}, but that did not work either.
I finally renamed the field in the source database to “Adresse”; then the join operation worked.
“Straße” was the only field with a different field name. When I changed it in the source database to the identical field name “Adresse”, the import worked.
It was not a problem with a German character — it seems to be a bug with different field names in general.
I renamed a field in my current database from “Stadt” (town) to “Ort” (place) and adjusted my above code accordingly. As I already suspected, the import of the “Stadt” data into the “Ort” field failed.
The problem is your code is incorrect. The field names MUST be enclosed in chevrons – that’s how the join statements knows these options are field names and not regular options. The correct code is:
I looked at the documentation and it does say that the field name needs to be enclosed in chevron characters, and all the examples show this, but perhaps this needs to be emphasized even more strongly, since it is a bit different from other uses of chevrons. Probably the join statement should have reported that Adresse, PLZ and Stadt were unknown options.
The only reason your code worked at all is because if no fields are specified, it defaults to assigning all fields that have the same name.
Recapping, the problem is, you needed chevrons around «Addresse» (and the other destination fields). Depending on the punctuation in the field names, you may also need it in the source formula, but it is always needed for the destination field.
Yes, indeed. With chevrons around all destination field names, the import works flawlessly — for both: pairs with identical and pairs with different field names.
I have added a clarifying paragraph to the join statement documentation:
Important: Note that the chevrons around the field names are significant, and cannot be omitted. When specifying a destination field name in the join statement, the field name must always be surrounded by chevron characters (« and »), even if the field name doesn’t have any spaces or punctuation. The join statement uses the chevron characters to identify which parameters are field names, and which are regular parameters. For example "Key" is a regular parameter, but "«Key»" would indicate a destination field name (in the current database).
Does that make it more clear?
I have also changed the code so that an error will be generated if it doesn’t recognize an option name.
I forget to add something that amused me to the release notes – Panorama X currently has exactly 2,222 help pages, a palindrome That won’t last long.
That won’t last long.