Forum Discussion

eminalasmx's avatar
eminalasmx
Regular Visitor
6 months ago
Solved

Error with setup Query Snowflake-managed Apache Iceber tables by using Microsoft Fabric

I am following this article https://docs.snowflake.com/en/user-guide/tables-iceberg-query-using-microsoft-fabric After completing step 7, snowflake database is created in fabric but with 500 interna...
one lake
  • eminalasmx's avatar
    eminalasmx
    6 months ago

    hi v-dineshya 
    At the end, while waiting for Microsoft to assist, issue got solved itself(I suspect Microsoft fixed all the internal issues they had after going GA on 1st February)
    Now I have a working snowflake which is replicating apache tables to fabrics.
    I have a snowflake and fabric in same region.

    Thanks!

MJParikh's avatar
MJParikh
Super User
6 months ago

This looks like a Fabric service-side failure, not a Snowflake SQL error. The key clue is HttpStatus 500 with ErrorCode InternalError, plus a requestId and user sessionId in the dialog. In this flow, Fabric is calling Snowflake and building the Fabric-side database metadata. When Fabric cannot complete that backend call, the UI often shows 500 with no helpful client log.

First, check the region and geo alignment, as this has the highest hit rate.

  1. Region and geo alignment

  • Confirm your fabric capacity and workspace regions align with your tenant’s data residency.

  • Confirm your Snowflake cloud account and region are supported for this integration.

  • A mismatch often produces “database created,” but queries and object discovery fail with 500.

  1. Snowflake network access controls

  • If your Snowflake account has network policies, IP allowlists, or restrictive firewall rules, Fabric’s outbound traffic gets blocked, and the Fabric UI reports 500.

  • Quick test: temporarily relax the restriction or test from a Snowflake account without a network policy to isolate.

  1. Permissions and role used by the connection

  • Validate the role mapped in the Fabric connection has usage on the warehouse and database schema, plus access to the Iceberg objects and related catalog metadata.

  • Also confirm the warehouse is running and not suspended with tight auto-suspend settings during setup.

  1. Propagation delay and transient backend faults

  • Wait a few minutes, then refresh the item. I have seen the first metadata pull fail and succeed on the next attempt, especially during preview rollouts.

If it still fails, raise a Microsoft support ticket and share the requestId and user sessionId so engineering can trace the backend call.


Thank you!
Proud to be a Super User!
📩 Need more help?
✔️ Don’t forget to Accept as Solution if this guidance worked for you.
💛 Your Like motivates me to keep helping

eminalasmx's avatar
eminalasmx
Regular Visitor
6 months ago

Hi MJParikh ,
My configuration is following
Microsoft Fabric Capacity:
Location: East US 2
Snowflake Account:
Location: Central US (Iowa)
Cloud: Azure

SQL Databases:
Location: East US (Virginia)

No network policies 

 

All permisions checked, everything is there. 
Thank you a lot for you help!
v-dineshya please share any thoughts 
I will raise a microosft support ticket with the requestId and user sessionId.


BIG NOTE WHICH I FORGOT TO MENTION:
This was working wihtout issues until 30th January, snowflake database was in preview back then, then it went GA
Previously it was like this 


Now it is

I've found out this 

 

https://docs.snowflake.com/en/release-notes/2026/other/2026-01-30-iceberg-microsoft-fabric-bidirectional-data-access-ga



  • v-dineshya's avatar
    v-dineshya
    Community Support
    6 months ago

    Hi eminalasmx ,

    Please try below workarounds.

     

    1. Move the workspace to a Central US capacity. Create or use a Fabric capacity in Central US matches Snowflake Central US. Assign your workspace to that capacity. Recreate the Snowflake database item or retry the connect steps.


    2. Keep East US 2, but change Snowflake region. Only do this if you can provision a new Snowflake account in East US 2 and migrate.

     

    Note: Make sure the role used by Fabric has USAGE on the warehouse, USAGE on the database & schema, and SELECT on objects and any Iceberg‑specific privileges if you are also doing write flows. Also ensure the warehouse can auto‑resume and isn’t immediately suspending during the initial sync.


    For the Snowflake integrations, ensure the relevant tenant settings are enabled (the Snowflake database item / OneLake external access settings). The tenant‑level API permissions used for Iceberg/OneLake operations.

     

    Please refer below links.

    Use Snowflake with Iceberg tables in OneLake - Microsoft Fabric | Microsoft Learn

    Microsoft OneLake and Snowflake interoperability (Generally Available) | Microsoft Fabric Blog | Microsoft Fabric

     

    I hope this information helps. Please do let us know if you have any further queries.

     

    Regards,

    Dinesh

    • eminalasmx's avatar
      eminalasmx
      Regular Visitor
      6 months ago

      Hi v-dineshya 

      I've tried option 1, same error.
      I can't try option 2 since I already have some production running things in snowflake.
      I will raise a microsoft ticket directly since I've lost a lot of time trying to figure it own on my own.

      Thank you so much for you help!

      • v-dineshya's avatar
        v-dineshya
        Community Support
        6 months ago

        Hi eminalasmx ,

        We are following up to inquire whether you have raised the support ticket. If you have already done so, we kindly request you to share your feedback regarding the issue raised.In case a solution has been provided, we would be grateful if you could share it with the community. This will assist others facing similar challenges and benefit the wider community. If you need any more assistance, please feel free to connect with the Microsoft Fabric community.

        Regards,

        Dinesh