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 internal error and I can't find any logs or anything.
I have tried to verify every step multiple times, everything is fine.
Any idea why I get this error?

 

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!

8 Replies

  • 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

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

      Hi eminalasmx ,

      Thank you for reaching out to the Microsoft Community Forum.

       

      Hi MJParikh ,  Thank you for your prompt responses.

       

      Hi eminalasmx , could you please try the proposed solution shared by MJParikh ? Let us know if you’re still facing the same issue we’ll be happy to assist you further.

       

      Regards,

      Dinesh

    • 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