I am using sql server 2016 and i have encrypted the column using always encryption option. I have connected sql with entity frameworking in ASP.NET MVC application. The dats are inserting properly using insert option. But i cant able to insert using stored procedure via mvc application. I am getting the following error
I have followed the below article.
https://www.codeproject.com/Articles/1110564/WebControls/
How can we refresh the stored procedure to apply encryption?
Error:
"The parameter \"#name\" does not have the same encryption information as the one it was created with. Use sp_refresh_parameter_encryption to refresh the parameter encryption information for the module."
The error message pretty self-explanatory in this case.
Since the encryption metadata has changed since the proc was created, you need to update it via running the sys.sp_refresh_parameter_encryption proc:
exec sys.sp_refresh_parameter_encryption 'SchemaName.ProcedureName'
Related
I have three tasks to do in my BizTalk orchestration
execute a stored procedure with dynamic parameters
do a insert into DB
do a update in DB
Example data
stored procedure [databasename].[storedprocedurename] 'param1Value', 'param2Value'
table [databasename].[tablename] (id integer,desc nvarchar(50))
UPDATE
Rephrase: Tasks are
How to call stored procedure from BizTalk orchestration with parameters from incoming XML message
How to do insert into DB table from orchestration (and get back result of operation)
How to do update with dynamic "where' value conditions from incoming xml
There is full documentation here: Executing Stored Procedures in SQL Server by Using BizTalk Server
High level overview:
Create your stored procedure (e.g. usp_Test) to do your inserts/updates. Include parameter(s) that would be used in your WHERE clause(s).
Use the Add->Add Generated Items->Consume Adapter Service to generate a schema and bindings file for the stored procedure.
Create a map from your message to the stored procedure schema
Update your Operation on the logical send port to match the SP name (usp_Test)
Deploy your Application.
Import the bindings for the physical send port from step 2 to your application
Bind the orchestration to this send port (or create a filter on the send port, perhaps based on BTS.Operation).
Create ports with the map set on the send port you've imported and a filter se the Orchestration).
BONUS:
Use table types to pass multiple inserts in a single call
Use CompositeOperations to call multiple procedures/tableops
CAVEATS:
The SQL Adapter doesn't like empty nodes (assuming you're using SQL Server). Make sure a node that is supposed to go in as a NULL is either set to xsi:nil=true (use the Nil functoid), or that it's not present in the destination (use a Value Mapping functoid, or a method to remove empty nodes in a pipeline or helper class).
Other adapters (Oracle or Db2 for example) will have their own particular challenges. IMO, the sqlBinding is the nicest to work with in terms of features available and documentation. If you know your other platform, you should be able to figure out the issues.
Avoid sending XML parameters unless you intend to store the XML in SQL Server. In other words, don't make SQL Server shred XML when you have BizTalk to do that for you - BizTalk will almost certainly do a better job (performance and development wise).
If you're returning data from SQL Server, consider using Strongly Typed (if your procedure result set is returned as a plain old SELECT or via OUTPUT parameters) or XML Polling (if your procedure returns a resultset using FOR XML). Avoid vanilla procedure calls unless you don't expect to deal with return data from the procedure.
Using VS 2013 (VB) and SQL Server 2012.
I execute a stored procedure to populate a gridview using linq.
Dim db As New GMConnectionDataContext
Dim gasHedges = db.GasHedges_create2ndMonth.ToList
The stored procedure returns a result set and has been working fine as in it returns the expected result and the gridview displays as desired.
I added some data to my SQL table and loaded the web page and the new data does not show. IF I execute the stored procedure in SQL Server the new data shows. If I execute the stored procedure in VS the new data shows.
Now the weird bit. If I delete the reference to the stored procedure from the .dbml file then re-add it the new data shows when the page is loaded. I know that when using this file if I add columns to a table then I need to delete it and re-add the table to the .dbml file.
Surely the same isn't the case with stored procedures as they would be unusable. Is there something I am missing?
UPDATED
I think I know why this happening but I don't know how to fix it. The SQL result set has dynamic columns as I use the pivot command in SQL. This means that if a user creates a new Gas company the result set will have another column and the datacontext must interpret that as the SP having changed and still shows the old dataset. This does mean I cannot just delete the SP from the datacontext and re-add it as the web application needs to handle if the user adds another company.
Any changes you make in SQL server are not auto-synched to your .dbml file. If you make table or stored procedure changes you need to delete them from the .dbml file and add them again.
Best practices would dictate that you don't pivot your data in SQL. Pivotting data is not a data related issue; it's presentation and should be done in the presentation layer -- in the application.
I am a new database intern working with a access front end and SQL server backend database. The database was custom made for the company. One of my assignments is to take scripts and apply them to make four new tables. I am aware that I need to make a new query for each new table but I don't know if I should make the query in SQL server management studio or the frontend access program. I have tried copying and pasting the given scripts into a new query in access but I get an error message "invalid SQL statement expected 'DELETE', 'INSERT'...". I decided to try to break done the program a little bit and tested the first line
IF EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id =OBJECT_ID(N'[dbo] .[FK_tblInstrumentInterfaceLog_tlkpInstrument]') AND parent_object_id = OBJECT_ID(N'[dbo].[tblInstrumentInterfaceLog]'))
but the same error message keeps popping up. I even tried just SELECT * FROM sys.foreign_keys, and I got the error message "could not find file...". I am very much a beginner and any guidance would be appreciated.Basically am I supposed to be applying these scripts the server SQL database or on the front end access program?
Are you using a pass-through query? i.e. not just a select query. Access needs to know where to send the query and since you are using TSQL not Access SQL this needs to be executed on the server.
Normally when you query a linked table the information of how to get the data (the connection string) is tied to the table. But for this kind of query you'll probably need to tell Access explicitly. Unless you are using an ADP/ADE, then the connection info travels with the program not the table.
As a general rule, you use SQL management studio (SSMS) to create and run those scripts. So the general accepted approach here is such scripts will not be placed in the front end. As noted such scripts if for some reason must be placed in the front end, then you have to create them as pass-though, but EVEN in this case you want to use the SSMS to create such quires.
So the answer here is you create the new scripts and make table queries in the back end, or in this case using the SQL server management studio.
The syntax checking, query editor etc. in recent versions of SSMS now has auto-complete etc. and you can test/write/update those scripts in SQL server. Once you have such a query or even several of them, then the resulting “several” statements can be pasted into a front end query that been created as pass-though. If you do not use a pass-though query, then you are creating and using and assuming client side SQL (JET (now called ACE)).
The client side has it own version of SQL syntax, and it is NOT 100% compatible with the SERVER SIDE. If you writing SQL in the client that is NOT pass though, then you using a linked table to SQL server. These linked tables thus will use local (JET/ACE) based SQL queries. The ODBC driver thus translates this SQL into server side compatible syntax. However the JET/ACE sql syntax is very limited when compared to SQL server and no server side commands exist in this SQL syntax for the client data engine (JET/ACE)
So for many quires, you will and can simply build such queries using the Access query builder.
However for SQL that needs to run 100% server side then such quires has to be setup as pass-though and are in most cased built + tested using SSMS.
When trying to automate reading out constraint information using sp_helpconstraint I got the bright idea of pulling out the source code of the built-in SP directly and run it myself (since it returns multiple result sets so those can't be stored in a temp table). So I ran exec sp_helptext 'sp_helpconstraint' (on SQL Azure) to generate the source code, and copied it into a new query window.
However, when I run the SP (on SQL Azure), I get lot's of error messages -- for example, that object syscomments doesn't exist even though I am using the exact same source that runs perfectly when calling sp_helpconstraint directly. Just to make sure it wasn't an anomaly with the procedure or a mistake in my copy/paste execution, I tested the exact same procedure on SQL Server 2008, and if I directly copy the SP source into a new query window, it runs perfectly (obviously after removing the return statements and manually setting the input parameters).
What gives?? Do built-in SP's run in a special context where more commands are available than normal on SQL Azure version? Is sp_helptext not returning the actual source that is being run on SQL Azure?
If you want me to try anything out, give a suggestion and I can try it on our SQL Azure Development instance. Thanks!
We have a database running on SQL 2005. One of the store procedure looks up a user's email address from Active Directory using a linked server. The call to the linked server occurs in a database function.
I'm able to call is successfully from my Asp.Net application the first time, but periodically after that, it fails with the following error:
{"The requested operation could not be performed because OLE DB provider \"ADsDSOObject\" for linked server \"ADSI\" does not support the required transaction interface."}
It appears that the amount of time between calling the function affects whether the linked server query will work correctly. I am not using any transactions. When I try calling the function in a quick make-shift SQL script, it runs fine everytime (even when tested in quick succession).
Is there some sort of transaction being left open that naturally dies if I don't try calling the procedure again? I'm at a loss here.
Here is the simple call in the store procedure:
DECLARE #email varchar(50)
SELECT #email = LEFT(mail, 50)
FROM OPENQUERY (
ADSI,
'SELECT mail, sAMAccountName FROM ''LDAP://DC=Katz,DC=COM'' WHERE objectCategory = ''Person'' AND objectClass = ''User'''
)
WHERE sAMAccountName = CAST(#LoginName AS varchar(35))
RETURN #email
I've worked with SQL Server linkservers often, though rarely LDAP queries... but I got curious and read the Microsoft support page linked to in Ric Tokyo's previous post. Towards the bottom it reads:
It is typical for a directory server
to enforce a server limitation on the
number of objects that will be
returned for a given query. This is to
prevent denial-of-service attacks and
network overloading. To properly query
the directory server, large queries
should be broken up into many smaller
ones. One way to do this is through a
process called paging. While paging is
available through ADSI's OLEDB
provider, there is currently no way
available to perform it from a SQL
distributed query. This means that the
total number of objects that can be
returned for a query is the server
limit. In the Windows 2000 Active
Directory, the default server limit is
1,000 objects.
I'm thinking that the reason it fails on you (or not) depending on whether call it from the app or from a "quick make-shift sql script" (as you put it) might be related to the security context under which the operation is executing. Depending on how the link server connection was set up, the operation could be being executed under a variety of possible credentials depending on how you initiate the query.
I don't know, but that's my best guess. I'd look at the linkserver configuration, in particular the linkserver settings for what set of credentials are used as the security context under which operations executed across the linkserver run.
Rather then query Active Directory through a linked server, you might be better off caching your AD data into a SQL database and then querying that instead. You could use Integration Services by creating a OLE DB connection using "OLE DB PRovider for Microsoft Directory Services" and having a DataReader source with a query like:
SELECT physicalDeliveryOfficeName, department, company, title, displayName, SN,
givenName, sAMAccountName, manager, mail, telephoneNumber, mobile
FROM 'LDAP://DC=SOMECO,DC=COM'
WHERE objectClass='User' and objectCategory = 'Person'
order by mail
Using this method you will still run into the 1000 row limit for results from an AD query (note it is NOT advisable to try and increase this limit in AD, it is there to prevent the domain controller from becoming overloaded). Sometimes its possible to use a combination of queries to return the full data set, e.g. names A - L and M - Z
Alternatively you could use the CSVDE command line utility in Windows Server to export your directory information to a CSV file and then import it into a SQL database (see http://computerperformance.co.uk/Logon/Logon_CSVDE_Export.htm for more info on exporting AD data with CSVDE).
please read the support page from Microsoft
I suspect that it might be the cached query plan due to your statement that "When I try calling the function in a quick make-shift SQL script, it runs fine everytime (even when tested in quick succession)."
Could you try executing your stored procedure like so:
EXEC usp_MyProcedure WITH RECOMPILE
This question appears in the top of the first google page when search for the error string but has not valid answer.
This error happens intermitently when isolation level is not specified on .NET code nor in Store Procedure.
This error also happens in SQL Server 2008.
The fix is force SET TRANSACTION ISOLATION LEVEL READ (UN)COMMITTED because a isolation level any higher is not supported by Active Directory and SQL Server is trying to use SERIALIZABLE.
Now, as this error is intermitent. Why is ADO.NET or SQLServer switching its default isolation to SERIALIZABLE sometimes and sometimes not? What triggers this switching?