To get

edr

to use the

elementary

profile you created in your

dbt

profiles.yml

, you need to ensure two things: 1. Your

profiles.yml

must contain a profile named

elementary

(not just your main dbt project profile). The

elementary

profile should have the correct connection details and schema where the Elementary tables are located. This is required because

edr

looks specifically for a profile named

elementary

in your `profiles.yml`—it does not use your main dbt project profile by default. If you only have your main project profile (e.g.,

my_project:

),

edr

will fail with "Could not find profile named 'elementary'" or may use the wrong schema/database if the profile is misconfigured [[Slack thread](https://slack.com/archives/C02CTC89LAX/p1686013979045139)]. 2. To select the correct target within the

elementary

profile, use the

--profile-target

(or

-t

) flag. For example, if your

elementary

profile has both

dev

and

prod

targets, you can run:

edr report --profile-target prod

This will instruct

edr

to use the

prod

target under the

elementary

profile [[Slack thread](https://slack.com/archives/C02CTC89LAX/p1700490053029329)]. Common pitfalls: - If you use

--profile-target

but your

profiles.yml

does not have a profile named

elementary

, or the

elementary

profile does not have the specified target,

edr

will not work as expected and may default to another target or fail entirely [[Slack thread](https://slack.com/archives/C02CTC89LAX/p1696334751498889)]. - The

--profile-target

flag only selects the target within the

elementary

profile, not the profile itself. The profile name must be

elementary

[[Slack thread](https://slack.com/archives/C02CTC89LAX/p1686013979045139)]. Example

profiles.yml

snippet:

yaml elementary:   outputs:     dev:       type: snowflake       database: DEV_DB       schema: ELEMENTARY       # ... other connection details ...     prod:       type: snowflake       database: PROD_DB       schema: ELEMENTARY       # ... other connection details ...   target: dev

To use the

prod

target:

edr report --profile-target prod

If you see a log message showing the wrong database/schema, double-check: - The

elementary

profile's

schema

and

database

fields match where your Elementary tables are actually created. - You are passing the correct target with

--profile-target

. - You are not relying on custom schema macros in your dbt project for Elementary CLI commands—`edr` only uses the static values in the

elementary

profile, not dynamic macros [[GitHub issue](https://github.com/elementary-data/elementary/issues/1462)]. If you need to use a different

profiles.yml

(not in the default location), use the

--profiles-dir

flag to specify its path. Summary: - Always define a profile named

elementary

in your

profiles.yml

. - Use

--profile-target <target>

to select the correct target within that profile. - The schema/database must match where Elementary tables are created. - Custom schema macros in

dbt_project.yml

are not used by `edr`—it reads only from the

elementary

profile [[GitHub issue](https://github.com/elementary-data/elementary/issues/1462)]. If you follow these steps and still see the wrong schema/database, double-check your

profiles.yml

for typos or misconfigurations.

The difference between

--profile-target

and

--project-profile-target

in Elementary CLI is: -

--profile-target

(or

-t

): This flag specifies which target to use within the

elementary

profile in your

profiles.yml

. It tells Elementary CLI which database/schema configuration to use for reading the Elementary tables. For example, if your

elementary

profile has both

dev

and

prod

targets, you would use

--profile-target prod

to select the

prod

configuration for Elementary [[CLI options documentation](https://docs.elementary-data.com/oss/cli-commands#cli-options)]. -

--project-profile-target

: This flag specifies which target to use for your main dbt project profile (not the

elementary

profile). This is relevant if your dbt project has multiple targets (e.g.,

dev

,

prod

) and you want to control which one is used when Elementary CLI interacts with your dbt project (for example, when uploading artifacts or running dbt commands as part of the report generation process) [[CLI options documentation](https://docs.elementary-data.com/oss/cli-commands#cli-options)]. Summary: -

--profile-target

→ selects the target for the

elementary

profile (where Elementary reads/writes its own tables). -

--project-profile-target

→ selects the target for your main dbt project profile (your data models and tests). This distinction is important when you have multiple environments or want to keep Elementary's metadata separate from your main dbt project's data [[Slack discussion](https://slack.com/archives/C02CTC89LAX/p1681336858403709)].

Perhaps the human <!subteam^S08HYBWCF6E> knows more?

It seems like maybe some dbt-specific environment variables I have set to control my dbt project are interfering with Elementary's internal dbt project? For example, if I

unset DBT_TARGET

and then invoke

edr

I get a different error message. I'll pull this thread a bit more and see if anything comes of it or if it's a red herring.

I got it to work:

# update the tables after an Elementary minor version update
dbt run --project-dir $DBT_PROJECT_DIR --target $DBT_TARGET --select elementary 

# clear out the env var we use to set the target for our main dbt project to prevent Elementary from using it
unset DBT_TARGET 

edr report --project-dir $DBT_PROJECT_DIR -p $DBT_PROFILES_DIR --profile-target default

The issue seems to be that the dbt-related environment variables were being unexpectedly used by Elementary's internal dbt project. Or at least it was "unexpected" to me. But I guess it makes sense that multiple dbt projects existing in different directories would share dbt-controlling env vars.