# How can I find which macro it is resolve from this call return(adapter.dispatch('make\_temp\_relation', 'dbt')(base\_relation, suffix))
**URL:** https://discourse.getdbt.com/t/how-can-i-find-which-macro-it-is-resolve-from-this-call-return-adapter-dispatch-make-temp-relation-dbt-base-relation-suffix/13150
**Category:** Help
**Tags:** dbt-core
**Created:** [May 1, 2024, 8:13pm UTC](https://discourse.getdbt.com/t/how-can-i-find-which-macro-it-is-resolve-from-this-call-return-adapter-dispatch-make-temp-relation-dbt-base-relation-suffix/13150 "2024-05-01T20:13:22Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@ortizfabio](https://discourse.getdbt.com/u/ortizfabio)
#### Post date: [May 1, 2024, 8:13pm UTC](https://discourse.getdbt.com/t/how-can-i-find-which-macro-it-is-resolve-from-this-call-return-adapter-dispatch-make-temp-relation-dbt-base-relation-suffix/13150/1 "2024-05-01T20:13:22Z")
I am using the incremental\_strategy=‘insert’ in one of my models. My adapter is Snowflake. The first time that I run the model everything works fine. But the second time an error is raised because a temp view that i created the same time is being delete the second time. The problem is that the adapter changes the view to a table and of course it fails.
Error in snowflake is “SQL compilation error: Object found is of type ‘VIEW’, not specified type ‘TABLE’.”
so I am trying to follow the call sequence to the culprit. which is as follows:
```auto
{% set tmp_relation_type = dbt_snowflake_get_tmp_relation_type(incremental_strategy, unique_key, 'sql') %}
```
Then it goes into dbt file dbt/include/global\_project/macros/adapters/relation.sql
```auto
{% macro make_temp_relation(base_relation, suffix='__dbt_tmp') %}
{{ return(adapter.dispatch('make_temp_relation', 'dbt')(base_relation, suffix)) }}
{% endmacro %}
```
I am not sure where that call resolves to. Can somebody please explain me where it goes?
---
### Author:  [@brunoszdl](https://discourse.getdbt.com/u/brunoszdl)
#### Post date: [May 2, 2024, 2:41am UTC](https://discourse.getdbt.com/t/how-can-i-find-which-macro-it-is-resolve-from-this-call-return-adapter-dispatch-make-temp-relation-dbt-base-relation-suffix/13150/2 "2024-05-02T02:41:23Z")
About the last question, when you use adapter.dispatch you have to look to the string you passed as the first argument. In this case, you have ‘make\_temp\_relation’.
What adapter.dispatch does is to search for macro named
` __make_temp_relation`, in your case `snowflake__ make_temp_relation`
If this macro does not exist it searched for `default__make_temp_relation`, that is defined [here](https://github.com/dbt-labs/dbt-adapters/blob/v1.1.0/dbt/include/global_project/macros/adapters/relation.sql#L13)
---
### Author:  [@ortizfabio](https://discourse.getdbt.com/u/ortizfabio)
#### Post date: [May 2, 2024, 1:44pm UTC](https://discourse.getdbt.com/t/how-can-i-find-which-macro-it-is-resolve-from-this-call-return-adapter-dispatch-make-temp-relation-dbt-base-relation-suffix/13150/3 "2024-05-02T13:44:28Z")
yes, it helped. I end up creating a new macro that dispatch to a Snowflake macro get\_drop\_view\_sql and I replace the call to that macro with the new one.
I will put here the solution if somebody have the same problem. Here is the new macro:
{% macro drop\_view\_relation\_if\_exists(relation) %}
{% if relation is not none %}
{{ return(adapter.dispatch(‘get\_drop\_view\_sql’)(relation)) }}
{% endif %}
{% endmacro %}
And this is what I changed in the current code to call the new macro:
From: {% do drop\_relation\_if\_exists(tmp\_relation) %}
To: {% do dc.drop\_view\_relation\_if\_exists(tmp\_relation) %}
---
### Author:  [@system](https://discourse.getdbt.com/u/system)
#### Post date: [May 9, 2024, 1:45pm UTC](https://discourse.getdbt.com/t/how-can-i-find-which-macro-it-is-resolve-from-this-call-return-adapter-dispatch-make-temp-relation-dbt-base-relation-suffix/13150/4 "2024-05-09T13:45:10Z")
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.