Options
SQL Doc and Azure SQL instance
Dave_the_Platypus
Posts: 2 New member
in SQL Doc
I have an issue with using SQL Doc against an Azure SQL instance. The documentation runs just find and there are no problems if I deploy the HTML output locally.
My problem is when I try to deploy the output as static content in a Blazor web site also hosted in Azure. Because SQL Doc uses the FQDN of the Azure server (myserver.database.windows.net) as a directory name, when you try to deploy the site as content it fails because the lowest level path name is too long. To get to the lowest level objects (like pages for tables or stored procedures) the entire path can't be longer than 256 characters. By the time you add in the web overhead (like the wwwroot directory name to get to the static content), this FQDN approach makes this undeployable.
I tinkered with using an alias via the SQL configuration manager and also via the HOSTS file. Neither will let SQL Doc log in - in fact, the actual error message is that the password is incorrect rather than that SQL Doc cannot find the host. In creating the aliases I have used both the FQDN and the IP address. Neither works.
In the previous version I could go into one of the top level HTM files and change the FQDN to a shortened name, change the directory name to match and then things worked just fine. The latest version seems to have changed the way in which the output is rendered, and instead of making a single change it looks like I have to change pretty much every file. Obviously this is pretty much impossible and actually defeats using SQL Doc during a database deployment.
Is there any way to change SQL Doc's behavior so the output is web-deployable?
My problem is when I try to deploy the output as static content in a Blazor web site also hosted in Azure. Because SQL Doc uses the FQDN of the Azure server (myserver.database.windows.net) as a directory name, when you try to deploy the site as content it fails because the lowest level path name is too long. To get to the lowest level objects (like pages for tables or stored procedures) the entire path can't be longer than 256 characters. By the time you add in the web overhead (like the wwwroot directory name to get to the static content), this FQDN approach makes this undeployable.
I tinkered with using an alias via the SQL configuration manager and also via the HOSTS file. Neither will let SQL Doc log in - in fact, the actual error message is that the password is incorrect rather than that SQL Doc cannot find the host. In creating the aliases I have used both the FQDN and the IP address. Neither works.
In the previous version I could go into one of the top level HTM files and change the FQDN to a shortened name, change the directory name to match and then things worked just fine. The latest version seems to have changed the way in which the output is rendered, and instead of making a single change it looks like I have to change pretty much every file. Obviously this is pretty much impossible and actually defeats using SQL Doc during a database deployment.
Is there any way to change SQL Doc's behavior so the output is web-deployable?
Tagged:
Answers
Sorry for the inconvenience this is causing you. As far as I know, we didn't intend to change this. Could you let us know in which version it used to work for you and what version are you on at the moment?
Thanks.
Tianjiao Li | Redgate Software
Have you visited our Help Center?
Tianjiao Li | Redgate Software
Have you visited our Help Center?