Tag: Database
Product shutterstock_246035320_1

Take Control of the Cache Manager

4D v16 introduced a new fully optimized cache manager for the 64-bit product line. 4D v16 R2 is giving power to our advanced 4D developers to take control by themselves!

The cache manager internal algorithm is based on a priority concept associated to each object type to store in the cache memory. By default, the cache manager algorithm assigns a higher priority value for an index than for records. And recently used objects (records or indexes) have a higher priority to remain in the cache than objects that have not been used in the last two days, etc…

Product cachemanager

Boost your performance with the new cache manager

The 4D v16 version has definitely been designed for better performance and scalability. In addition to major features like preemptive multi-threading, 4D v16 64-bit is embedding a brand new cache manager for a optimized handling of objects in cache memory avoiding any fragmentation issues.

The new cache manager improves the usage of very large cache for modern computers (with 64 or even 128 GB of Cache) allowing to take advantage of low RAM prices to have even large databases fully in memory. It also improves the situation of small cache size with very large data files, by decreasing the amount of unloading memory with increased support of priorities for data objects to be hold or released from cache.

Product objectfields

Go further with Object fields

Object fields introduced with v15 allows unstructured data bases, similar to schemaless database (NoSQL). 4D v16 goes a big step further. Get a dynamic structure for unstructured data… Confused?

Imagine you use an object field to allow your customers to store custom data, where they can create their own fields. This works well and is one of the most interesting reasons for using an object field. The problem is, how to allow your customer to query this unstructured data? You don’t know which ‘fields’ they used, you cannot build a query editor on top or offer a drop down with used values.

Product shutterstock_94703131

Database mirroring

When integrating the log file, 4D stops at the first error and doesn’t return any error message. Reasons for integration errors could be a damaged log, by example because of a bad hard disk or software error during writing. If that error happens at the end, no problem; but it could also be at the start or in the middle of the log. In this case, the data after the error might be useful.

Now, when the integration fails in standard mode, you can try integration in auto-repair mode. In this case, 4D tries to resolve the error encountered, doesn’t stop the integration, and returns the error list.

Product shutterstock_474524959

JSON export for Journal

In 4D applications, the data file is important, so all the activity of the database is stored in the log file. As you all know, the log file is a vital element for the restoration of your database following an unfortunate contingency. However all the information on the database activity may also be useful for analysis. For example, to check the activity on a table, to see the changes made by a user, and to follow a record’s history.

Product duplicatefield

Report duplicates in unique fields

In 4D v15 R3, the way to detect duplicates in fields declared as unique has been enhanced so that users have a mean to know which are the offending fields.

What’s new? All the offending fields are now displayed in an error message or in the log.

Duplicates can be reported through 2 different ways:

  • when 4D needs to create indexes on a database with offending fields.
  • during an MSC Verify scan.