[Bug]: Follow-up to issue 1973 (varchar/nvarchar slowness), but related to Azure SQL views instead of tables

[tdutch1]

What happened?

Please see issue 1973. The DAB team fixed the problem where the dynamically generated select statements (on an Azure SQL table) were specifying nvarchar even though the column in the where clause was varchar. This prevented Azure SQL from using the index on the column. For a table of millions of records, DAB queries took several seconds to complete instead of the usual < 1 second. The same problem exists for Azure SQL views: If you create a view and query via DAB, DAB appears to default to nvarchar, even though the queried column is a varchar. In the case of a table with about 20 million rows, the DAB queries on the view are taking about 15 seconds. When we copied the data to a new table and set the varchar column to nvarchar, the same DAB query on the view took only 250 ms. So, it's clear that the same nvarchar/varchar issue exists for views as it did for tables.

Version

Latest; we're using DAB in a Container Instance and the latest version is always applied

What database are you using?

Azure SQL

What hosting model are you using?

Container Apps

Which API approach are you accessing DAB through?

REST

Relevant log output

Code of Conduct

• [x] I agree to follow this project's Code of Conduct