You are here:
Considerations, Guidelines, and Limitations for Data 360 SQL Migration (Beta)
Keep these considerations, guidelines, and limitations in mind when migrating custom SQL queries to Data 360 SQL.
Considerations
- Data 360 SQL uses the Data 360 Direct SQL (HyperSQL) version instead of the legacy TrinoSQL version.
- Legacy SQL and Data 360 SQL handle NULL values differently. Legacy SQL always places NULL values last. Data 360 SQL defaults to NULLS LAST for ascending sorts but changes to NULLS FIRST for descending sorts.
- Data 360 SQL returns dates in UTC using offset notation (for example, +00:00), whereas legacy SQL uses the Zulu suffix (for example, Z).
- Data 360 SQL supports high-volume data queries and has improved Experience Page Time (EPT) compared to legacy SQL.
- When measure values are identical, legacy SQL and Data 360 SQL use different default tie-breaking logic. Because of this, rows appear in a different order between the two systems during tie-breaking scenarios. This visual row shift is expected behavior, and you don't lose any data.
- Data 360 SQL supports pagination in Values Table assets and efficiently handles large datasets by fetching data on demand through infinite scrolling.
Guidelines
- Back up your dashboard JSON or asset XMD file before you migrate a Custom SQL widget. This step preserves your conditional formatting rules.
- To make sure your queries work correctly, wrap all column aliases and identifiers in double quotes. Data 360 SQL is case-sensitive and requires this formatting to match your data exactly.
- To prevent broken conditional formatting and maintain consistent casing in Freeform queries, use aliases such as SELECT Field_c AS "Field_c". Both Legacy SQL and Data 360 SQL preserve query-defined casing when you use an alias, even if the alias is unquoted. However, for un-aliased fields, Data 360 SQL reverts to the original data source casing.
- Review your queries for legacy SQL functions such as TO_UNIXTIME and convert them to Data 360 SQL equivalents.
- To make sure your data remains accurate, explicitly add NULLS LAST to your queries or verify your sort logic. Data 360 SQL changes the default null ordering, which causes unexpected results in your tables and charts.
- Use unique aliases for every field to prevent data rendering issues in the UI.
- To make sure your dashboard remains functional, verify that faceting works correctly when you use global filters on Custom SQL widgets. Complex nested SQL often causes filtering issues that lead to inaccurate data or broken visualizations.
- When you enable the "Disable paginated loading" option on a table widget, the query doesn't
re-run immediately. The table still shows truncated data from the previous paginated state. To
load all rows, save and reload the dashboard. If the issue continues, verify that:
- The step is a legacy AGGREGATE type.
- Data SQL and pagination gates are enabled.
- To access supported syntax and analytical functions, click the Info icon next to the Data 360 SQL option in the custom SQL editor.
Limitations
- Colors and styles disappear if key casing doesn't match the expected format. This issue occurs because Data 360 SQL preserves the original casing of keys, while legacy XMD mappings typically expect lowercase keys.
- Data 360 SQL lacks direct equivalents for some legacy SQL functions. This mismatch breaks free-form formulas during migration.
Did this article solve your issue?
Let us know so we can improve!
