Project Databases: Post conversion

Automatically translated from English

In this blog post, we showed you how to convert a binary database into a project database. Once everything is ready and the conversion has successfully completed, you can start working with your project database. However, some questions may arise: are all the files in the database useful? It’s obvious that the”.4DB” structure file is no longer needed. Can I delete other files?

Here’s everything you need to know after the conversion.

The Structure

For a binary database, the description of your application is stored in two files (.4DB and.4DIndy). For a project database, you’ll find this description in the files stored in the “Project” folder.

So after conversion, you can remove both of the following files:

  • <database>.4db
  • <database>.4dIndy


For more details on the architecture of a project database, check out this blog post.


During the development phase, it’s often easier to have the data next to the structure (e.g., testing, transferring to another computer, etc.). However many of 4D’s new features use the “next to the data” concept to save certain parameters or files, so during development tests how can you be sure that you’re using the file next to the data and not the file next to the structure?

For new project databases, 4D creates a “Data” folder at the same level as the “Project” folder. Thus even during the development phase, a file located next to the data is different from a file located next to the structure.

Therefore after conversion, we recommend that you:

    1. Create a Data folder at the same level as the Project folder.
    2. Move the data.4dd and data.4DIndx files into your new Data folder.




4D has user preferences for the 4D environment, user preferences for the database, and settings for the database.

  • User preferences for the 4D environment include, for example, the syntax color of methods. For both binary and project databases, these preferences are stored in a “4D Preferences vXX.4DPreferences” file.
  • User preferences or configurations for the database include things such as the list of opened windows, the position of breakpoints, and so on. For a binary database, this information is saved in the .4DB files. For a project database, this information is saved in several files in a “userPreferences.<name>” folder.
  • Settings for the database include preferences for configuring a backup or building the application, etc.


To summarize, 4D uses the word “preferences” for user parameters that are related to each other and the term “settings” for parameters related to the database.

For more information, you can read this blog post.

A concrete example

In this video, you’ll find the “Contacts” database that we converted in a previous blog post.

First, we’ll reiterate the concepts above in a diagram, then we’ll show you the result with the “Contacts” database.

Vanessa Talbot

• Product Owner •

Vanessa Talbot joined 4D Program team in June, 2014. As a Product Owner, she is in charge of writing the user stories then translating it to functional specifications. Her role is also to make sure that the feature implementation delivered is meeting the customer need.

Since her arrival, she has worked to define key features in 4D. She has worked on most of preemptive multi-threading new features and also on a very complex subject: the new architecture for engined application. Vanessa has a degree from Telecom Saint-Etienne. She began her career at the Criminal Research Institute as a developer for the audiovisual department. She has also worked in media and medical fields as expert in technical support, production as well as documenting new features.