Guard fabric__get_use_database_sql against database=None

[sdebruyn]

Fixes #395.

Summary

Wraps fabric__get_use_database_sql in a None-guard so it no longer renders USE [None]; when called with database=None.

Background

dbt-core's default__drop_schema_named builds a relation via api.Relation.create(schema=schema_name) — i.e. without a database — and hands it to drop_schema. fabric__drop_schema then calls fabric__get_use_database_sql(relation.database), which today is:

{%- macro fabric__get_use_database_sql(database) -%}
  USE [{{database | replace('"', '') | replace('[', '') | replace(']', '')}}];
{%- endmacro -%}

If database is None, Jinja renders the string "None", producing USE [None]; — an Invalid object name 'None' T-SQL error. dbt run-operation drop_schema_named fails, and the error gives no hint about the underlying database handling.

Change

Wrap the USE [...] statement in {% if database is not none %}. When database is None the macro now renders nothing, leaving the connection's current database context untouched (which is what the caller wants for drop_schema_named).

Test plan

• dbt run-operation drop_schema_named --args '{schema_name: foo}' no longer fails with Invalid object name 'None' and drops the schema in the current database
• dbt run against a model with an explicit database: config still emits USE [...] with the correct catalog (existing behaviour unchanged)
• dbt-tests-adapter's BaseDropSchemaNamed passes