Alex C.
My feedback
-
8 votes
Thank you for your feedback folks. We are actively looking into this scenario specifically with VS SSDT Database Project support with SQL Data Warehouse. Please continue voting and monitoring this item for updates. Thank you for your patience.
An error occurred while saving the comment Alex C.
shared this idea
·
-
16 votes
Is this the looping execution time or the actual time of creating the tables?
Alex C.
shared this idea
·
-
233 votesAlex C.
supported this idea
·
-
13 votes
Thanks for the request. This item is currently on our backlog. We will update this thread when the state changes.
Alex C.
shared this idea
·
-
15 votes
Thanks for your suggestion. We are looking into this scenario for a future release. 10703219
An error occurred while saving the comment Alex C.
commented
Going the stored procedure way does not work out....
SET @variable = exec sproc @input 'parameter1' does not work....This means running calculations with functions/sprocs which access table data is not possible at all at this moment. An official statement on the product roadmap on whether this feature will be introduced or not would be very appreciated.
An error occurred while saving the comment Alex C.
commented
Context ist still Azure SQL Data Warehouse.
I meant this link:
An error occurred while saving the comment Alex C.
commented
Hi JRJ, thank you very much for pointing to the documentation. Is it possible to rewrite the function into a stored procedure and use OUTPUT variables for this purpose (https://msdn.microsoft.com/en-US/library/ms187926.aspx)?
Best regards,
AlexAn error occurred while saving the comment Alex C.
commented
Of course the Configuration table contains values. And of course it contains one value with the parameter "parameter1"...
An error occurred while saving the comment Alex C.
commented
The result of the SELECT dbo.get_param('parameter1') statement is NULL.
Alex C.
supported this idea
·
An error occurred while saving the comment Alex C.
commented
CREATE TABLE [dbo].[Configuration] (
[Parameter] nvarchar(50) NOT NULL,
[Value] nvarchar(255) NULL,
[Description] nvarchar(200) NULL
)
WITH (CLUSTERED COLUMNSTORE INDEX, DISTRIBUTION = ROUND_ROBIN);CREATE FUNCTION [dbo].[get_param] (@value nvarchar(255))
RETURNS nvarchar(255)
AS
BEGIN
RETURN
(SELECT TOP 1
g.Value as v
FROM
dbo.Configuration as g
WHERE
g.Parameter = N'currency')
ENDSELECT dbo.get_param('parameter1')
-
79 votesAlex C.
supported this idea
·
I believe I used SQL Server Management Studio and Visual Studio 2013. I tried to reproduce the error message today and now I can see that the “Debug”-functionality is disabled in both tools.
I did not use a database project specifically. In our team we used Team Foundation Server and we had one folder with the “old” scripts (SQL Server 2008 R2) and one folder with the “new” scripts (Azure SQL DW). When migrating the scripts we opened a connection to the DW and ran the “create stored procedure” scripts. After the stored procedure was created we executed it to test whether it works well. In some cases we had errors. In on prem scenarios we use the SSMS-debugger to analyze the execution of commands in order to identify bugs. In the DW-scenario we were missing that feature so finding errors took a lot more time. Either full compatibility between on prem SQL language features and Azure SQL DW language features or the debugging functionality in Azure SQL DW would be very beneficial.
Thank you and best regards,
Alex