Temp Table return data from Stored procedure doesnot create Modal class in Entity c# and it returns int.
Select Test 1,test2,test3,test4 from #temp1
sql side working and get the as expected after adding this procedure to my entity frame work result set is not generating instead of class it is generating int class
Please suggest is anything wrong done from side.
And also suggest whether temp table returns Result columns in entity.
Add SET FMTONLY OFF in SP that will work
Related
Evening,
I'm trying to exec a stored procedure into a temporary table so I can join some bits from another table.
Obviously the ideal solution would be to add the join into the stored procedure however this is currently not an option.
Here's what I'm trying to run in my controller action:
db.Query<HomeLatestTradesViewModel>(Sql.Builder
.Append("INSERT INTO #tmp_trade")
.Append("EXEC get_trade_data_latest")
);
Which hits me with:
Invalid object name 'HomeLatestTradesViewModel'.
I believe this is because I need a ; before the EXEC however that just throws an error telling me it shouldn't be there!
Any help getting this to work is appreciated.
If you want to execute (not retrieve data), you should use
db.Execute(Sql.Builder
.Append(";INSERT INTO #tmp_trade")
.Append("EXEC get_trade_data_latest")
);
(but I guess this wont work, depends on how have you create the temp table, and if you are in a transaction)
If you want to fiddle with temp data, you are better getting the data into a list, and then playing with it
var templist = db.Query<HomeLatestTradesViewModel>(Sql.Builder
.Append("EXEC get_trade_data_latest")
);
I'm trying to call a Stored proc from BizTalk. I have seen many tutorials doing this. Only issue is, once I Consume Adapter -> connect to DB-> select a SP to run, the resulting schema doesn't have any the return values from the Stored proc (I assume this is what is meant to happen). Therefore I can't map the resulting schema to the one I want.
Please correct me if I wrong.
This is my understanding:
Consume an Adapter, call a SP from the database in which there are some select statements.
This should result in a schema being generated which should have all the returned columns from the SP. (Do I have to add the output dataset which the SP will return to the schema manually? )
Map this to the desired schema
Output the result.
Number 2 is not correct;
2.This should result in a schema being generated which should have all the returned columns from the SP. (Do I have to add the output dataset which the SP will return to the schema manually? )
this happens only when you are defining output parameters in your SP, if your stored procedure is returning a record set from select statement the columns will be generated but in the run time, you can get the values with xpath.
in schema design you will only find a generated element of type any xml.
In Oracle this should be a very simple thing but I only started working with procedures a day ago and I'm having some trouble with this. I created a procedure that's supposed to receive a type of facility as a parameter, say 'healthcare' for instance.
create or replace
PROCEDURE Adminfacility(
v_facility_type IN VARCHAR2)
IS
BEGIN
...(SELECT goes here)...
END Adminfacility
Is this right? How do I make the procedure receive the parameter and then return a table of two columns? (Facility ID's and respective admins for instance). One problem I'm having is that it requires me to have an INTO after the SELECT statement. I've done something of the kind before with functions where you'd input a numerical ID and receive a number output, but I've never done this kind of thing before.
I've done a similar thing as a view (where it has a default facility type) and it works, but I can't get it to work as a procedure.
CREATE PROC Adminfacility
#text NVARCHAR(MAX)
AS
BEGIN
SELECT id,adminname
FROM TABLE
WHERE TEXT =#text
END
This is accepting text as parameter using it in where condition and then return a table.
if you want to change already existing proc then instead of CREATE write ALTER
In the application I'm working on porting to the web, we currently dynamically access different tables at runtime from run to run, based on a "template" string that is specified. I would like to move the burden of doing that back to the database now that we are moving to SQL server, so I don't have to mess with a dynamic GridView. I thought of writing a Table-valued UDF with a parameter for the table name and one for the query WHERE clause.
I entered the following for my UDF but obviously it doesn't work. Is there any way to take a varchar or string of some kind and get a table reference that can work in the FROM clause?
CREATE FUNCTION TemplateSelector
(
#template varchar(40),
#code varchar(80)
)
RETURNS TABLE
AS
RETURN
(
SELECT * FROM #template WHERE ProductionCode = #code
)
Or some other way of getting a result set similar in concept to this. Basically all records in the table indicated by the varchar #template with the matching ProductionCode of the #code.
I get the error "Must declare the table variable "#template"", so SQL server probably things I'm trying to select from a table variable.
On Edit: Yeah I don't need to do it in a function, I can run Stored Procs, I've just not written any of them before.
CREATE PROCEDURE TemplateSelector
(
#template varchar(40),
#code varchar(80)
)
AS
EXEC('SELECT * FROM ' + #template + ' WHERE ProductionCode = ' + #code)
This works, though it's not a UDF.
The only way to do this is with the exec command.
Also, you have to move it out to a stored proc instead of a function. Apparently functions can't execute dynamic sql.
The only way that this would be possible is with dynamic SQL, however, dynamic SQL is not supported by SqlServer within a function.
I'm sorry to say that I'm quite sure that it is NOT possible to do this within a function.
If you were working with stored procedures it would be possible.
Also, it should be noted that, be replacing the table name in the query, you've destroyed SQL Server's ability to cache the execution plan for the query. This pretty much reduces the advantage of using a UDF or SP to nil. You might as well just call the SQL query directly.
I have a finite number of tables that I want to be able to address, so I could writing something using IF, that tests #template for matches with a number of values and for each match runs
SELECT * FROM TEMPLATENAME WHERE ProductionCode = #code
It sounds like that is a better option
If you have numerous tables with identical structure, it usually means you haven't designed your database in a normal form. You should unify these into one table. You may need to give this table one more attribute column to distinguish the data sets.
I'm using SQL Server 2005, and I would like to know how to access different result sets from within transact-sql. The following stored procedure returns two result sets, how do I access them from, for example, another stored procedure?
CREATE PROCEDURE getOrder (#orderId as numeric) AS
BEGIN
select order_address, order_number from order_table where order_id = #orderId
select item, number_of_items, cost from order_line where order_id = #orderId
END
I need to be able to iterate through both result sets individually.
EDIT: Just to clarify the question, I want to test the stored procedures. I have a set of stored procedures which are used from a VB.NET client, which return multiple result sets. These are not going to be changed to a table valued function, I can't in fact change the procedures at all. Changing the procedure is not an option.
The result sets returned by the procedures are not the same data types or number of columns.
The short answer is: you can't do it.
From T-SQL there is no way to access multiple results of a nested stored procedure call, without changing the stored procedure as others have suggested.
To be complete, if the procedure were returning a single result, you could insert it into a temp table or table variable with the following syntax:
INSERT INTO #Table (...columns...)
EXEC MySproc ...parameters...
You can use the same syntax for a procedure that returns multiple results, but it will only process the first result, the rest will be discarded.
I was easily able to do this by creating a SQL2005 CLR stored procedure which contained an internal dataset.
You see, a new SqlDataAdapter will .Fill a multiple-result-set sproc into a multiple-table dataset by default. The data in these tables can in turn be inserted into #Temp tables in the calling sproc you wish to write. dataset.ReadXmlSchema will show you the schema of each result set.
Step 1: Begin writing the sproc which will read the data from the multi-result-set sproc
a. Create a separate table for each result set according to the schema.
CREATE PROCEDURE [dbo].[usp_SF_Read] AS
SET NOCOUNT ON;
CREATE TABLE #Table01 (Document_ID VARCHAR(100)
, Document_status_definition_uid INT
, Document_status_Code VARCHAR(100)
, Attachment_count INT
, PRIMARY KEY (Document_ID));
b. At this point you may need to declare a cursor to repetitively call the CLR sproc you will create here:
Step 2: Make the CLR Sproc
Partial Public Class StoredProcedures
<Microsoft.SqlServer.Server.SqlProcedure()> _
Public Shared Sub usp_SF_ReadSFIntoTables()
End Sub
End Class
a. Connect using New SqlConnection("context connection=true").
b. Set up a command object (cmd) to contain the multiple-result-set sproc.
c. Get all the data using the following:
Dim dataset As DataSet = New DataSet
With New SqlDataAdapter(cmd)
.Fill(dataset) ' get all the data.
End With
'you can use dataset.ReadXmlSchema at this point...
d. Iterate over each table and insert every row into the appropriate temp table (which you created in step one above).
Final note:
In my experience, you may wish to enforce some relationships between your tables so you know which batch each record came from.
That's all there was to it!
~ Shaun, Near Seattle
There is a kludge that you can do as well. Add an optional parameter N int to your sproc. Default the value of N to -1. If the value of N is -1, then do every one of your selects. Otherwise, do the Nth select and only the Nth select.
For example,
if (N = -1 or N = 0)
select ...
if (N = -1 or N = 1)
select ...
The callers of your sproc who do not specify N will get a result set with more than one tables. If you need to extract one or more of these tables from another sproc, simply call your sproc specifying a value for N. You'll have to call the sproc one time for each table you wish to extract. Inefficient if you need more than one table from the result set, but it does work in pure TSQL.
Note that there's an extra, undocumented limitation to the INSERT INTO ... EXEC statement: it cannot be nested. That is, the stored proc that the EXEC calls (or any that it calls in turn) cannot itself do an INSERT INTO ... EXEC. It appears that there's a single scratchpad per process that accumulates the result, and if they're nested you'll get an error when the caller opens this up, and then the callee tries to open it again.
Matthieu, you'd need to maintain separate temp tables for each "type" of result. Also, if you're executing the same one multiple times, you might need to add an extra column to that result to indicate which call it resulted from.
Sadly it is impossible to do this. The problem is, of course, that there is no SQL Syntax to allow it. It happens 'beneath the hood' of course, but you can't get at these other results in TSQL, only from the application via ODBC or whatever.
There is a way round it, as with most things. The trick is to use ole automation in TSQL to create an ADODB object which opens each resultset in turn and write the results to the tables you nominate (or do whatever you want with the resultsets). you can also do it in DMO if you enjoy pain.
There are two ways to do this easily. Either stick the results in a temp table and then reference the temp table from your sproc. The other alternative is to put the results into an XML variable that is used as an OUTPUT variable.
There are, however, pros and cons to both of these options. With a temporary table, you'll need to add code to the script that creates the calling procedure to create the temporary table before modifying the procedure. Also, you should clean up the temp table at the end of the procedure.
With the XML, it can be memory intensive and slow.
You could select them into temp tables or write table valued functions to return result sets. Are asking how to iterate through the result sets?