I am trying to run the SQL Transport Schema Generation Wizard against a SQL 2012 server. The stored procedure has a datetime parameter. If i simply put in a date like 12/26/2013 05:00:00 Am, then the "Generate" button doesn't show an argument. If i try putting the date/time in a single quote or using a string like 2013-12-26T05:00:00.000, the parameter is generated, but i get the following error when i try to execute. "Failed to execute SQL Statement. Please ensure that the supplied syntax is correct. "
I got to this point by creating a SQL Query that output it's response using FOR XML AUTO, ELEMENTS in it. I then open my BizTalk solution in VS 2012, Go to "Add Items -> Add Generated Items". Select Add Adapter Metadata. From there, it asks the location of the message box. I use my local server. It then asks for the connection string for the SQL Server with the stored procedure. I enter that (it's the same as the server with the message box). I specify the namespace and the root element name for the document. This is set as a receive port. I next select stored procedure and move to the next screen. I then select the stored proc from a drop down list. Below, in a grid, i am shown the parameters for the stored proc. Here is where i am having trouble. I cannot seem to get it to accept the datetime argument no matter what i put in here.
Is there something i am doing wrong?
It is better to do the following steps and to use the new WCF-SQL rather than the old deprecated SQL adapter.
Add Items
Add Generated Items
Consume Adapter Service
Select sqlBinding and Configure the URI
Click Connect
Select Client (Outbound operations)
Select Strongly-Type Procedures
Select the Stored Procedure from Available categories and operations
Click Add
Give it a Filename Prefix
Click OK
This will generated the schemas plus binding files to create the port.
You also don't need to have the FOR XML AUTO, ELEMENTS in your stored procedure any more.
Related
I am designing an ETL project on SSIS and I want it to be dynamic. I will use this project for many customers therefore I will query these extractions against different servers.
For example, I have this query in a step with "execute SQL task" component :
INSERT DataWarehouse.schema.fact1
SELECT *
FROM Database.schema.table1
My datawarehouse is always in localhost But "Database.schema.table1" could be in different servers therefore I will have Different linkservers in our customer's servers to retrieve its data.
This means for example I will need the query change like this for customer1 :
INSERT DataWarehouse.schema.fact1
SELECT *
FROM [192.168.1.100].Database.schema.table1
And for customer2 I will need the query to be like this :
INSERT DataWarehouse.schema.fact1
SELECT *
FROM [10.2.5.100].Database.schema.table1
I've tried extract and loading with SSIS components but because of my complex queries, It became so messy.
Any ideas how to make my query dynamic?
As per this link Changing Properties of a Linked Server in SQL Server
One way to solve your problem is to make sure that the linked server logical name is always the same, regardless of what the actual physical host is.
So the process here would be:
Create the linked server with the linked server wizard
Use this to rename the server to a consistent name that can be used in your code
i.e.
EXEC master.dbo.sp_serveroption
#server=N'192.168.1.100',
#optname=N'name',
#optvalue=N'ALinkedServer'
Now you can refer to ALinkedServer in your code
A better way is to script the linked server creation properly - don't use the SSMS wizard
Here's the template - you need to do more research to fund out the correct values here
USE master;
GO
EXEC sp_addlinkedserver
#server = 'ConsistentServerName',
#srvproduct = 'product name',
#provider = 'provider name',
#datasrc = 'ActualPhysicalServerName',
#location = 'location',
#provstr = 'provider string',
#catalog = 'catalog';
GO
But the last word is: Don't use linked servers. Use SSIS
I would suggest you to do the below steps to execute same statement across multiple servers. As suggested by #Nick.McDermaid, I would strongly recommend against linked server. It is better to go for exact server name in SSIS.
Put the INSERT statement into a separate variable
Create a foreach container in SSIS.
Inside foreach containter, have a script task and get the current server name from the list of servernames. You can have comma separated list of servernames and get current one.
Again, inside foreach container, create Execute Process Task & call Sqlcmd.exe with connection information specific to each server, based on the server name got in Step No. 3, using SSIS expressions. Refer to this Stackoverflow post on using expressions for Execute ProcessTask for more information on calling Execute process task in SSIS.
How about making a SSIS package that works for one of your systems.
Parameterize your working package to accept a connection string
create another package that loops thru your connection strings and calls your working package and passes the conn string
In a BIDS project, after selecting Reports > Add New Report, and adding a connection string as the Shared Data Source in the Report Wizard, the wizard next prompts for a query (in the "Design the Query" page of the wizard).
I want to specify an existing Stored Procedure. How can I do that? Is it possible to specify it directly in the connection string? e.g, I provided something like this as the connection string:
SERVER=GoCards2016;DATABASE=platypusdata;UID=duckbill;PWD=dannyAndTheJuniors;Connection Timeout=0
Can I also insert the Stored Procedure to use in there somewhere?
Or do I need to enter a bogus query in the "Design the Query" page of the wizard and later replace it in the .rdl (xml) file with the Stored Procedure name? Or...???
The Report Wizard will let you only use Query strings so you can't select a stored procedure, but You can use the EXEC statement to specify a stored procedure to run.
exec my_stored_procedure_name
Click through the wizard, then, in the "Data" tab, change the Command Type from Text to Stored Procedure and enter the name of your Stored Procedure.
So, with a little more specific instructions:
In the “Design the Query” page of the wizard, either enter “Exec [sp name]” or just enter some temporary query such as “select * from [tableName]” and then, once the Report Wizard has completed, in the data tab of the report, change the “Command type:” dropdown from Text to “Stored Procedure” and then enter the name of the Stored Procedure below.
Mash the “!” (Run) button to generate the data.
Open Reports
In Solution Explorer Right Click on Reports
Click on Add New Report
Click on Next
Select the Data source and click on Next
Click on Query Builder button
Click on "Edit As Text"
In Command Type Select StoredProcedure
Enter the Stored Procedure Name ONLY in the text box
Click OK. The window should close
Click Next
Configure
Finish
From: https://social.msdn.microsoft.com/Forums/en-US/7ddcb6a4-03f8-461e-9caa-01c058812f01/using-stored-procedure-with-report-wizard?forum=sqlreportingservices
I am using a GUID for a batch identifier in SSIS. My final output goes to SQL Server.
I know how I can generate one using Select NewId() MyUniqueIdentifier in Sql Server - I can generate one using a query and an Execute SQL task.
I am however looking to do this within a SSIS package if possible without SQL Server available.
Can I generate a GUID within SSIS?
I had a similar problem. To fix it, I created an SSIS "Composant Script" in which I created a "guid" output. The script VS C# code was the following :
Row.guid = Guid.NewGuid();
Finally, I routed the output as a derived column into my database "OLE DB Destination" to generate a guid for every new entry.
Simply do it in an Execute SQL Task.
Open the task
Under General -> SQL Statement, enter your query Select NewID() MyID in the "SQLStatement" field
Under General -> Result Set, choose "Single row"
Under Parameter Mapping, Enter your User::myID in Variable Name, "Input" as direction, 0 as Parameter Name, and -1 as Parameter Size
Under Result Set, enter "MyID" for your Result Name and type the variable in Variable Name
-Click OK
Done. Note that "MyID" is a value you can choose. EDIT: "User::myID" corresponds to the SSIS variable that you create.
Is there a setting in the management studio that would allow me, when I create a new query, to use just:
SELECT * FROM Foo
instead of
SELECT * FROM dbname.dbo.Foo
assuming of course there is no ambiguity?
Currently I get an error message. Thanks.
You can set a default schema for a User in SQL Server 2012.
Here is the MSDN page
Note: You can't change the schema after setting it once.
SELECT YOUR DATABASE NAME HERE FROM THE DROP DOWN LIST and then if there is any ambiguity in column names just use two part name i.e TABLENAME.ColumnName
WHere you open a new query window it opens it in Master database context, And people who has been working with sql server for years and years makes this mistake quite often of openning a query window and start executing a script in master db. so your not the only one :)
You can also use the USE statement i.e
USE DataBase_Name
GO
//your query.........
So I have a stored procedure in SQL Server. I've simplified its code (for this question) to just this:
CREATE PROCEDURE dbo.DimensionLookup as
BEGIN
select DimensionID, DimensionField from DimensionTable
inner join Reference on Reference.ID = DimensionTable.ReferenceID
END
In SSIS on SQL Server 2012, I have a Lookup component with the following source command:
EXECUTE dbo.DimensionLookup WITH RESULT SETS (
(DimensionID int, DimensionField nvarchar(700) )
)
When I run this procedure in Preview mode in BIDS, it returns the two columns correctly. When I run the package in BIDS, it runs correctly.
But when I deploy it out to the SSIS catalog (the same server the database is on), point it to the same data sources, etc. - it fails with the message:
EXECUTE statement failed because its WITH RESULT SETS clause specified 2 column(s) for result set number 1, but the statement sent
3 column(s) at run time.
Steps Tried So Far:
Adding a third column to the result set - I get a different error, VS_NEEDSNEWMETADATA - which makes sense, kind of proof there's no third column.
SQL Profiler - I see this:
exec sp_prepare #p1 output,NULL,N'EXECUTE dbo.DimensionLookup WITH RESULT SETS ((
DimensionID int, DimensionField nvarchar(700)))',1
SET FMTONLY ON exec sp_execute 1 SET FMTONLY OFF
So it's trying to use FMTONLY to get the result set data ... needless to say, running SET FMTONLY ON and then running the command in SSMS myself yields .. just the two columns.
SET NOTCOUNT ON - Nothing changed.
So, two other interesting things:
I deployed it out to my local SQL 2012 install and it worked fine, same connections, etc. So it may be a server / database configuration. Not sure what if anything it is, I didn't install the dev server and my own install was pretty much click through vanilla.
Perhaps the most interesting thing. If I remove the join from the procedure's statement so it just becomes
select DimensionID, DimensionField from DimensionTable
It goes back to just sending 2 columns in the result set! So adding a join, without adding any additional output columns, ups the result set to 3 columns. Even if I add 6 more joins, just 3 columns. So one guess is its some sort of metadata column that only gets activated when there's a join.
Anyway, as you can imagine, it's driving me kind of mad. I have a workaround to load the data into a temp table and just return that, but why won't this work? What extra column is being sent back? Why only when I add a join?
Gah!
So all credit to billinkc: The reason is because of a patch.
In Version 11.0.2100.60, SSIS Lookup SQL command metadata is gathered using the old SET FMTONLY method. Unfortunately, this doesn't work in 2012, as the Books Online entry on SET FMTONLY helpfully notes:
Do not use this feature. This feature has been replaced by sp_describe_first_result_set.
Too bad they didn't follow their own advice!
This has been patched as of version 11.0.2218.0. Metadata is correctly gathered using the sp_describe_first_result_set system stored procedure.
This can happen if the specified WITH results set in SSIS identifies that there are more columns than being returned by the stored proc being called. Check your stored proc and ensure that you have the correct number of output columns as the WITH results set.