Compatibility settings – all the rest (Part 4)

We began a series of blog posts on compatibility settings and the secret options that can drastically help improve the performance and  behavior of your applications (QUERY BY FORMULA, Transactions and period and comma). This final post of the series will give an overview of the remaining settings.

Here’s an example of a structure created many years ago. The compatibility options are disabled, meaning it’s running entirely in v17 mode.

Keep in mind that compatibility settings allow you to emulate an older behavior, but they’re not supposed to be permanent. They grant you extended migration time, but don’t wait too long … over time migration options disappear. Considering that newly created structures don’t allow using these old settings they’re tested less and less, increasing the risk of unexpected behaviors.

Unicode mode

OS X, Windows NT, and 4D v11 (and newer) are designed for and running Unicode only. 4D’s database engine only works with Unicode. The language supports a compatibility mode, where each executed line converts text to/from Unicode in order to emulate MacRoman encoding handling. And yes, this decrease performance. For the past 10 years, there have been many tech notes, 4D Summit sessions and trainings about how to migrate to Unicode. If not already done, it’s time to start now.

With Unicode enabled, you should enable the “Save methods as Unicode” compatibility setting as well. Once enabled, every new parsed method is saved in Unicode, allowing extended character sets to be used as literals in your code. There is no compatibility issue with saving methods in Unicode, except if you use old plugins to directly read/write methods (which have been deprecated for a long time now).

Last (but DEFINITELY not least), object notation is only possible with Unicode.

Use date type instead of ISO date format in objects

This option is new in v17, check out the dates inside objects blog post to learn more.

Use new architecture for application deployments

This option eases the creation of read-only applications and since the path to the last used server or data file is no longer stored inside the application, it also helps deploying updates. Find out more in this blog post.

Prevent drop of data not coming from 4D

If this setting is enabled, your applications still run in 4D v2004 mode, where dragging and dropping from other applications into 4D (other than text and pictures) wasn’t possible.

If not already done, the time has come to support drag and drop. For more information, read the Drag and Drop and Managing pasteboard chapters in the documentation.

Do not use new context referencing mode

This setting is so old, I honestly don’t even remember if this emulates 4D 6.0 or 6.5.

If you don’t use 4D’s Web Server, just disable it. If you do use it, it’s enabled, and you haven’t touched your code in 15 years, it’s time for an update …

Remove “/” on unknown URLs

This sets the Web Server to 4D v2003 mode. If this setting is enabled, it’s time to rewrite your code.

Automatic variable assignment

If enabled: URGENT – READ THIS NOW!

This is a potential security problem, possibly huge one (depending on your code).

20 years ago this was a comfort feature which was quickly replaced with a more secure approach (and required more coding).

When enabled, HTML variables used in a HTML form are automatically mapped to 4D variables as long they are defined in Compiler_Web. While only a small subset of variables are typically defined there, a potential threat remains that those variables could be overwritten from a hacker.

A better way to assign variables (introduced with 4D 6.5) is to use WEB GET VARIABLES.

4D strongly recommends that you rewrite your code (if necessary) and disable this setting.

… in conclusion

This final post completes the series about compatibility settings, we hope you enjoyed it. Now revel in your new compatibility knowledge and have fun configuring your applications to run safely and optimally!