Hi @gaurang033 ,                                                                                                                                                               I'm not an Iceberg expert, but I did some research and tests and I think I can point you in the right direction.                

The error you're seeing (more than 2 name parts. SQLSTATE: 42601) happens because, I suppose, Databricks SQL does not support 4-part identifiers in the FROM clause — so catalog.schema.table.snapshots gets rejected by the SQL parser.

But there's also a deeper reason: in Databricks, CREATE TABLE ... USING iceberg doesn't always create a true native Iceberg table. The behavior depends on whether Predictive Optimization is enabled on your workspace:

- Without Predictive Optimization → Databricks creates a Delta table with Iceberg UniForm (Iceberg metadata is generated asynchronously on top of Delta). In this case, use DESCRIBE HISTORY to inspect snapshots:

DESCRIBE HISTORY raw.landing.emp_ice;

- With Predictive Optimization → Databricks creates a native managed Iceberg table. In this case, the .snapshots syntax should work, but only via PySpark (not Databricks SQL):

spark.sql("SELECT * FROM raw.landing.emp_ice.snapshots").display()

To check which type of table you actually have, run:

DESCRIBE EXTENDED raw.landing.emp_ice;

- If you see a Delta Uniform Iceberg section → it's a Delta+UniForm table → use DESCRIBE HISTORY

- If you see Provider: iceberg without Delta references → it's a native Iceberg table → use PySpark

You can also check the Iceberg metadata generation status with:

SHOW TBLPROPERTIES raw.landing.emp_ice;

and look for converted_delta_version and converted_delta_timestamp.

Hope this helps! If you found my answer useful, feel free to give me a Kudo 🙂