I have below SP:
CREATE PROCEDURE [dbo].[ups_Ins_TblA] #ID int, #Comment nvarchar(max) AS
BEGIN
SET NOCOUNT ON
INSERT INTO [db_assets].[Claim]
(ID,Comment)
Values
(#ID,#Comment)
END
Basically, my question is, is there a way to call this in BCS Sharepoint(Business Connectivity Service) using out-of-the-box functionality? Can I further adjust the SP so that it can be supported with all 'CRUD' operations? Pls suggest ideas?
Note: I have made the table as simple as possible.
I don't want to make a straight-insert from the table because I have to join this to another table where document resides that's why I want to use SP.
I'd been spending almost 2-3days reading and still going on.. If anyone can direct me to the light, pls help? Thank you so much!!
This is a noob mistake. Apologies.
The answer is to write your stored procedure separately and assign it the each operation accordingly (Read Item, read List, Create, Update, Delete).
Yes, there will be 5 sp.
As long as the mapping of identifier is set appropriately, the creation of Lists will not have issue (with CRUD operation enabled).
Related
I'm doing investigation of code repo and find one thing that make me confused. SQL Server stored procedures are contained in a repo as a set of queries with following structure:
IF OBJECT_ID(N'[dbo].[sp_ProcTitle]', N'P') IS NULL
BEGIN
EXEC dbo.sp_executeSQL N'CREATE PROCEDURE [dbo].[sp_ProcTitle] AS dummy:;';
END
ALTER PROCEDURE dbo.sp_ProcTitle
#ParamOne int,
#ParamTwo date,
#ParamThree int
AS
SET NOCOUNT ON
-- some procedure body
END
Never before I saw AS dummy:; and now I'm a little confused, I can't find any good explanation what is it and how it works. Could anybody tell me what does it mean this statement? How it works? What is the reason to have it? Any thought would be good to hear. Or, please, advise me some link where I can find good explanation.
This is simply a label, such that could be used in a GOTO statement.
The word "dummy" is unimportant. It's simply trying to create the stored procedure if it doesn't exist, with a minimal amount of text. The content is then filled in with the ALTER.
Conceivably, the dummy text could later be searched for to see if any procedures were created and didn't have their content filled in, to check against failed deployments, etc.
Why do this? Well, it preserve the creation time of the stored procedure in metadata (which can be useful in administration or tracking down problems), and is compatible with versions of SQL Server that lack the CREATE OR ALTER... support.
This might make a little more sense if we add a little formatting to the CREATE:
CREATE PROCEDURE [dbo].[sp_ProcTitle]
AS
dummy:
This is, effectively, an empty procedure with a label called dummy. The user appears to be using this to ensure that the procedure exists first, and the ALTERing it. In older versions of SQL Server, such methods were needed because it didn't support CREATE OR ALTER syntax. As such, if you tried to ALTER a procedure that didn't exist the statement failed, and likewise if you try to CREATE a procedure that already exists it fails.
If you are on a recent version of SQL Server, I'd suggest changing to CREATE OR ALTER and getting rid of the call to sys.sp_executesql.
I would like to update data in a table (for sqlserver and oralce version).
I created a stored procedure as below, but i would like to convert it to SQL function, is it possible to update data within SQL function please?
CREATE PROCEDURE updatetable (#A1 INTEGER, #A2 VARCHAR(4000) )
AS
BEGIN
BEGIN
UPDATE table SET column1= column1+ #A1 WHERE column2= #A2 ;
END
END
For SQL Server.
Simply put:
No.
A function can't change the system (really gross and dangerous hacks aside). From the documentation (emphasis mine):
Specifies that a series of Transact-SQL statements, which together do not produce a side effect such as modifying a table
If you can explain what you're trying to accomplish with a function that you can't accomplish with a stored procedure, you might be asking a question that has more than a yes/no answer, and you might get useful alternatives.
I am receiving an error trying to build a macro using a stored procedure with a cursor.
Some relevant details need to be included. This is for a document in an Electronic Health Records system. First, I develop the templates/tables, then I create document macros to pull all the information into the EHR documents. I have used stored procedures hundreds of times, so I know that it is the cursor that is causing it to fail.
All I do is pass in the parameters and it creates a grid on the document. Whether or not it is a limitation of the software that is used to create the documents, I don't know. I figured I would ask here to make sure my code is correct.
Here is my table:
txt_enc_id enc_id_generate
12345 93847
12345 75430
12345 93946
I am passing in the enc_id on the document macro, which will match up to the txt_enc_id column, and I need a stored procedure to run for each of the enc_id_generate rows in that table
Here's what I have for my stored procedure:
#enc_id VARCHAR(36)
AS
BEGIN
SET NOCOUNT ON
DECLARE #enc_id_generate VARCHAR(36)
DECLARE enc_id_cursor CURSOR
FOR
(SELECT enc_id_generate
FROM my_table
WHERE txt_enc_id = #enc_id)
OPEN enc_id_cursor
FETCH NEXT FROM enc_id_cursor INTO #enc_id_generate
WHILE ##FETCH_STATUS = 0
BEGIN
-- Here is the stored procedure that needs to run for each record.
-- The only parameter it uses is #enc_id_generate
FETCH NEXT FROM enc_id_cursor INTO #enc_id_generate
END
CLOSE enc_id_cursor
DEALLOCATE enc_id_cursor
SET NOCOUNT OFF
END
When I try to create the macro, I pass in the #enc_id, click ok in the parameter window, and I am getting this error:
Failed to update the macro builder window.
Cannot find table 0.
Do I somehow need to NOT have the stored procedure inside the cursor, and somehow call it to execute? I don't know how to do that. I am not a SQL guru, so forgive me if I have murdered this code. I do know that cursors should be used sparingly, but the table holding those Encounter IDs will rarely have more than 2 or 3 records.
I hope this makes sense. Thanks in advance for any advice you may have.
Lyn
Given:
code inside a stored proc:
select bleh
into #tblTemp
from FunctionThatReturnsTable('some','params')
-- do some stuff
drop table #tblTemp
-- Error on this command:
-- 'There is already an object named '#tblTemp' in the database.'
select bleh
into #tblTemp
from FunctionThatReturnsTable('some','other params')
Problem:
I can't recreate this temp table. My work around is to use #tmpTable1, #tmpTable2, #tempTable3 etc. Is there a way I can get around this? It would be nice just use one temp table each time.
If not, what is the reason for this?
As my comment reflected, I'm going to suggest that the answer is that you use a different #temp table name for each object that you create. It's kind of like saying to the doctor, "it hurts when I do this." His likely response is going to be, "stop doing that!"
The reason this is a problem is that SQL Server's parser attempts to parse the entire batch in one shot. It can clearly see that you are trying to create the same #temp table multiple times, but ignores the DROP command in between (I can't tell you exactly why that is, as I don't have access to the source code). This is the same reason you can't do this:
IF (1=1)
CREATE TABLE #foo(i INT);
ELSE
CREATE TABLE #foo(i VARCHAR(32));
The parser sees the two identical names, but can't really follow the IF/ELSE logic.
In addition to avoiding the problems multiple identically-named #temp tables causes the parser, another benefit to using unique names is that they can be re-used if you don't explicitly drop them. This will lighten the load on tempdb in terms of metadata / locking.
I ran into this problem with deleting+inserting column. The problem is probably with the parser, that it 'recognizes' the table on first create, and cannot see it was deleted.
I'd suggest using exec sp_executesql 'create table'
This is a feature by design and is clarified by Microsoft against Microsoft Connect Bug ID 666430
Please see a case study on the same at
temporary-table-could-not-be-re-created
I have a Stored Procedure that rolls-back a series of operations. I want to call this from within another SP.
The problem is that the inner SP returns a record set with a single value that indicates the degree of success.
This approach worked well and has some advantages in our context, but in retrospect, I would have done it the conventional way with a Return value or an Output parameter.
I could always change this SP to use this approach and modify the calling code, but a) I don't want to dabble with any more code than I have to, and b) at an intellectual level, I'm curious to see what alternative solution there may be, if any.
How (if at all) can I call this SP and determine the value of the singleton recordset returned?
Thanks
A stored procedure returns a record set like any other, so you can actually do this:
INSERT INTO MyTable (
MyValue
)
EXEC dbo.MyStoredProcedure
The EXEC takes the place of a SELECT statement. To get the value, just SELECT from the table you inserted into. Typically, this would be a temp table.
The other option is to convert the stored procedure that returns a recordset into a function that returns a table.
Ant's approach is probably best if you want to minimize the changes to your system.
Normally you would use a temporary table for that approach since you can't use an exec statement to insert into a table variable.
Here's a variation which will work well if you need to use this for MULTIPLE recordsets.
CREATE TABLE #outsidetable (...)
exec spInsideProcedure
SELECT * FROM #outsidetable
inside spInsideProcedure
INSERT INTO #outsidetable SELECT <blah blah blah>
I tried Ant's approach and it worked a treat:
Declare #Success tinyint
Declare #Response Table (Success int)
Insert into #Response(Success)
Exec Fix_RollbackReturn 12345, 15
Select #Success=Success from #Response
As you can see I used a Table Variable rather than a temporary table because slightly more efficient than a temporary table.
Thanks for all your help guys.
EDIT: It appears that Dave was right after all. That is, my Exec-into-Table-variable approach worked on my SQL2005 development machine, but when moved to the Live (SQL2000) machine it objected, so I had to change to the temporary table approach.
It's a little annoying, especially since in a couple of weeks we are upgrading to SQL2005 across the board(!).