Forum Discussion
Lakehouse Table Generate Create Table
One final update on this.
The logfile containing the schema is not necessarily the most recent, and there is not necessarily only one version of the schema. There is a schema associated with every modification made to the table structure, be that the original creation or subsequent alterations. Consequently, the logfile we need is the most recent with a schema.
from delta.tables import DeltaTableimport json# Note that the table name must be lowercasetable_path = '<Path_To_Table>'# Identify log fileslog_dir = f"{table_path}/_delta_log"files = [f.path for f in notebookutils.fs.ls(log_dir) if f.name.endswith(".json")]# Identify log files with a schemafilesWithSchema = []for file in sorted(files, reverse=True) :content = notebookutils.fs.head(file, 5000000)JSONdocs = content.split('\n')for doc in JSONdocs:if 'schemaString' in doc:filesWithSchema.append(file)# Load the header for the latest log file containing a schemalatest = sorted(filesWithSchema, reverse=True)[0]content = notebookutils.fs.head(latest, 5000000)# Extract the schemaJSONdocs = content.split('\n')for doc in JSONdocs:if 'schemaString' in doc:schemaString = json.loads(doc).get("metaData", {}).get("schemaString")# Extract Field MetadataFieldList = []OrdinalPosition = 0for field in json.loads(schemaString).get("fields") :OrdinalPosition += 1FieldDetails = {}FieldDetails['FieldName'] = field.get("name")FieldDetails['Nullable'] = field.get("nullable")FieldDetails['OrdinalPosition'] = OrdinalPositionmatch field.get("type").split('(')[0]:case 'string':FieldDetails['SQLType'] = field.get("metadata").get("__CHAR_VARCHAR_TYPE_STRING")case 'timestamp':FieldDetails['SQLType'] = 'timestamp'case 'date':FieldDetails['SQLType'] = 'date'case 'integer':FieldDetails['SQLType'] = 'int'case 'short':FieldDetails['SQLType'] = 'smallint'case 'long':FieldDetails['SQLType'] = 'bigint'case 'decimal':FieldDetails['SQLType'] = field.get("type")case 'boolean':FieldDetails['SQLType'] = 'boolean'FieldList.append(FieldDetails)display(FieldList)
Hi JonBFabric,
✅ Why this happens
- Delta tables in Fabric do not enforce fixed-length character types like CHAR(n) or VARCHAR(n); they store text as variable-length strings.
- The SQL endpoint maps these to STRING for compatibility, so the original length constraint is not preserved.
✅ Why CHARACTER_MAXIMUM_LENGTH shows 4x
- The SQL endpoint assumes UTF-16 encoding internally, so the reported length is multiplied by 4.
- This is a known limitation and does not affect actual storage or query behaviour.
What is a lakehouse? - Microsoft Fabric | Microsoft Learn
Table utility commands | Delta Lake
If this response was helpful in any way, I’d gladly accept a 👍much like the joy of seeing a DAX measure work first time without needing another FILTER.
Please mark it as the correct solution. It helps other community members find their way faster (and saves them from another endless loop 🌀.
Thanks. Great to get the explanation as to what is happening and why. But going back to the original question...
Is it possible to identify the SQL statement used to originally create a table? I'm getting the impression that the answer is no. And given that the maximum record length that can be handled by the SQL endpoint is 8060 bytes, those character limits are crucial and need to be tightly controlled.
Hi JonBFabric , Thank you for reaching out to the Microsoft Community Forum.
Fabric lakehouse cannot return the original CREATE TABLE statement because that information is never stored. Delta Lake only keeps a structural schema in its transaction log and all string columns are recorded simply as string without any notion of the original CHAR(n) or VARCHAR(n) definitions. Because the lakehouse storage layer does not preserve fixed length constraints, there is no system level metadata you can query later to recover them.
The SQL analytics endpoint also cannot help because it exposes a compatibility projection rather than the real underlying schema. Its inflated character lengths, including the 4× multiplier and the cap at 8000 are generated by the endpoint itself and do not represent the actual table definition or any original DDL. That surface is designed for querying, not schema reconstruction and therefore does not retain the information you are looking for.
Given these constraints, there is no reliable way to extract the exact SQL used to create a lakehouse table after the fact. If those character limits matter for downstream SQL workloads, the only viable approach is to rebuild the DDL by measuring actual data lengths in the table and defining controlled column sizes going forward. For future tables, the only dependable method is to version control the DDL at creation time or store it explicitly as metadata, because the platform does not preserve it automatically.
What Is Data Warehousing in Microsoft Fabric? - Microsoft Fabric | Microsoft Learn
What is a lakehouse? - Microsoft Fabric | Microsoft Learn
Data Types in Fabric Data Warehouse - Microsoft Fabric | Microsoft Learn
What is the SQL analytics endpoint for a lakehouse? - Microsoft Fabric | Microsoft Learn
Whilst I understand everything that you are saying, I would like to describe another scenario which suggests that some of the above is not actually correct.
Using only SparkSQL in a notebook I have created a lakehouse table with a single varchar(10) field. If I try to insert any value with more than 10 characters I get the following error:
[DELTA_EXCEED_CHAR_VARCHAR_LIMIT] Exceeds char/varchar type length limitation. Failed check: (isnull('String) OR (length('String) <= 10)).
Obviously something in the spark engine or the delta table metadata ia storing the size restriction
Hi JonBFabric , Thank you for reaching out to the Microsoft Community Forum.
Yes, Spark/Delta can record and enforce CHAR(n) / VARCHAR(n) when a table is created through Spark or other Delta-aware APIs; the engine stores that constraint in the Delta metadata and will reject writes that exceed the declared width (hence the DELTA_EXCEED_CHAR_VARCHAR_LIMIT error). The authoritative place to get that declaration is the Spark/Delta surface (for example, run SHOW CREATE TABLE or DESCRIBE TABLE EXTENDED in a Spark notebook or read the Delta transaction log/Delta Table API). Those commands return the DDL/metadata that Spark/Delta actually enforces.
Do not rely on the Fabric SQL analytics endpoint or INFORMATION_SCHEMA alone to recover declared widths. Those surfaces present a T-SQL compatibility projection that can inflate, cap or otherwise transform reported lengths (the 4×/8000 behaviour you saw) and therefore are not a trustworthy source of the original Spark declared sizes. If you cannot run Spark against the table, your fallback is to inspect the _delta_log or compute observed max character/byte lengths and reconstruct conservative VARCHAR widths and for long term safety you must version-control the DDL or persist it as table metadata at creation time.
