Hi Kenta,
If you're using the Database Connection document approach from the External Database Connector, then unfortunately the connection constants generated by each Database Connection document are tied to that specific document.
In other words, there is no built-in mechanism where multiple Database Connection documents can directly reference a single shared set of constants and automatically inherit changes.
If all your existing queries already use Database Connection documents, the easiest option is usually to:
For existing projects, however, if dozens of Database Connection documents already exist, changing the password in one place and having every document automatically pick it up is not something the connector currently supports.
One workaround I've seen is to use the same constant names and manage them through environment/configuration settings, but each Database Connection document still keeps its own generated constants behind the scenes.
So the answer to your question is essentially:
✅ Multiple Query External Database activities can share credentials.
✅ Multiple modules can share a common Database Connection document.
❌ Multiple Database Connection documents cannot natively point to one central credential definition without modifying the existing configuration.
If your goal is simply "change the password once for all developers", I would seriously consider consolidating the Database Connection documents into a shared module. It requires some initial cleanup, but it eliminates the maintenance burden you're experiencing today.
Unfortunately, I am not aware of a Mendix feature that allows existing Database Connection documents to reference another document's credentials dynamically.
Hi Kenta,
Yes, in Studio Pro 11.12 you can manage the database credentials centrally, without changing your SQL queries.
Why you currently have to configure every module
Each Database Connection document automatically creates its own three constants: <DocumentName>_DBSource, <DocumentName>_DBUsername and <DocumentName>_DBPassword. Every developer module has its own connection document, so every module has its own constants, and the credentials have to be entered again for each one.
Solution: one shared set of credentials for all modules
Since Studio Pro 11.1, the Query External Database activity has connection parameters (DBSource, DBUsername, DBPassword) in its General section. You can point every activity to one shared set of
constants:
Result
This is a one-time change per activity. After that, every module uses the same credentials:
Each developer can also keep their own configuration with private values.
Tip: Going forward, consider one Database Connection document per external database in a shared module, and let all developer modules call its queries. That keeps everything in one place.
For deployed environments: On Mendix Cloud, set Shared.DB_Source, Shared.DB_Username and Shared.DB_Password per environment under Environment Details → Model Options → Constants. These values are not copied from Studio Pro.
Kindly accept the answer if it resolves your query.
Hi Kenta,
You can simplify this by centralizing the connection settings instead of maintaining separate credentials manually across multiple modules.
The External Database Connector creates three constants for each database connection:
DBSourceDBUsernameDBPasswordThese constants are configurable per environment. However, if each module has its own External Database Connection document, each document generates its own set of constants.
I would suggest two approaches:
Option 1: Use a shared configuration
If the modules connect to the same database, check whether you can reuse a single External Database Connection document across those modules. This avoids maintaining duplicate connection definitions and credentials.
Option 2: Use connection parameters (Studio Pro 11.1+)
The External Database Connector supports dynamic connection values through connection parameters in the Query External Database activity. This can be useful when you need to select connection details at runtime without changing your saved SQL queries.
For centralized configuration across many connections, you can also consider a configuration entity or a shared configuration microflow, depending on how your application is structured.
Security note: Avoid storing database passwords as ordinary text in a configuration entity unless you have a secure secret-management approach. Use protected environment-specific configuration values or an approved secrets manager.
References:
Hope this helps.