I have a user defined SQL function that I am able to call from management studio using syntax dbo.Function(arg)
Now, when I have to call this function from C# if I don't specify **dbname**.dbo.Function(arg) I get an error that SQL server does not find this user defined function. How can I solve this without specifing dbname ? I already connect to the server using a connection string that specifies the "initial catalog = dbname"
It seems that I cannot reproduce mentioned behavior at this point :-) (either using SQL server 2005 or 2008) I have to put this question on hold
Your connection string needs to specify the database to use initially. It might look something like this:
var cn = new SqlConnection(
"SERVER=SomeServer;DATABASE=SomeDb;Integrated Security=SSPI;"
);
Without that, you're probably being dumped into the master database, which is why you need to fully qualify the function name.
Related
We move data from Oracle 11 to SQL 2014 using SSIS project deployment model. We use Attunity 3.0 connector.
Connection string to oracle data source is a project parameter and is also stored in a table in SQL.
We use custom stored procedure that
Gets this connection string stored in the sql table
sets project parameters (via [SSISDB].[catalog].[set_execution_parameter_value] )
executes packages (via [SSISDB].[catalog].[start_execution] )
We use [SSISDB].[internal].[execution_parameter_values] to check that parameter values are being replaced during run time with the connection string we stored in the backend.
What's interesting is that, even though Oracle connection string is being replaced during runtime, the package still tries to use the connection string it has been complied with(Project Params). We do not have the same issue when connecting to a SQL Source in a similar fashion.
Do you have any suggestions? Is it a known issue?
Found the solution. Turns out that the oracle connection string that we stored in the table did not prefix the server name with "SERVER = ". The connection string would straight away start with For Eg - 'x1abc01.something.com:1234/x1abc01;ORACLEHOME=;ORACLEHOME64=;WINAUTH=0;'. Changed the connection string to 'SERVER = x1abc01.something.com:1234/x1abc01;ORACLEHOME=;ORACLEHOME64=;WINAUTH=0;' and it started working now. We tested it by deploying the ssis solution with one connection string and changing it with a different connection string from the database and the overwritten value persists.
However, its still bizarre where the disconnect happens when the run time connection string has an invalid value and its not reported out as an error and ssis quietly switches to design time value in Project Param.
My code and the Linq to sql function SubmitChanges are working, but when using a local database a copy of the database in the bin folder is updated and not the primary database. So the changes aren't shown on a new query. If I re-connect the database but don't load it as local same problem - the primary database isn't updated, but now I can't figure out which one is (tks to this question).
What setting for a local db or how do I use a non-local database to show changes on a new query of the database?
Dim DATA As New lnqPolarisDataContext
Dim newBOOK As New BOOK()
newBOOK.ID = 14
newBOOK.LEG = 11
newBOOK.P_C = "C"
newBOOK.STRATEGY = "STRADDLE"
newBOOK.STRIKE = 999
newBOOK.CONTRACT = "XXX"
DATA.BOOKs.InsertOnSubmit(newBOOK)
DATA.SubmitChanges()
... new query doesn't show these changes
maybe this is the best method?
The real solution in my opinion would be to put your database on the server where it belongs - after all, SQL Server is a server-based solution, not a file-based "database".....
install SQL Server Express (and you've already done that anyway)
install SQL Server Management Studio Express
create your database in SSMS Express, give it a logical name (e.g. YourDatabase)
connect to it using its logical database name (given when you create it on the server) - and don't mess around with physical database files and user instances. In that case, your connection string would be something like:
Data Source=.\\SQLEXPRESS;Database=YourDatabase;Integrated Security=True
and everything else is exactly the same as before...
Also see Aaron Bertrand's excellent blog post Bad habits to kick: using AttachDbFileName for more background info.
What is the use of mentioning the database name in connection string while opening a connection from dot net application to SQL server? Because even though we mention a database name in connection string we have to explicitly write the fully qualified name (DBName.schemaName.ProcName) while calling a stored procedure if the default DB is different for that particular user.
Connecting to database from a .NET application is different from accessing a table of different database.
use of mentioning the database name in connection string
so for instance you can use connection string below to connect to myDB at MyServer
Data Source=MyServer;Initial Catalog=myDB;Integrated Security=True
if you will not specify at least these information how your .NET application can connect to a stored procedure (MyProcInMyDB) located in myDB.
Now for part you asked
though we mention a database name while calling a stored procedure if
the default DB is different for that particular user
this is not a normal case to access stored procedure of another database using same connection string if it is a very special case (not likely) then you will do it for calling one or two stored procedures. But if it is required quite often within your application then you should create a separate connection string. Using same connection string and calling like
command.CommandText = "myDB2.dbo.getList"
can result is difficult maintenance and flexibility
Following along with an example I found on the internet, I wrote the following C# code that implements a CLR stored procedure in MS SQL Server 2008:
public class Class1
{
[Microsoft.SqlServer.Server.SqlProcedure]
public static void CountStringLength(string inputString)
{
SqlContext.Pipe.Send(inputString.Length.ToString());
}
}
This procedure takes a string as a parameter and outputs the number of characters in the string.
I have been working on some code that retrieves data from SQL; there's nothing special about the way the data is retrieved: it makes a connection to the SQL server, selects the data, and then closes the connection. I want to make this code run inside a stored procedure or trigger on my SQL server.
I suppose that I could make the code run exactly the same as the existing SQL code: make a connection to the SQL server, select the data, and then close the connection. However, this doesn't make sense once the code is running on the SQL server itself! Why would I want code that runs on the SQL server make the server connect to itself?!?!
Is there a best practice for what I'm trying to do? Can I select rows in my code using the same connection that is used to execute the stored procedure?
I found the answer explained here: http://technet.microsoft.com/en-us/library/ms131053.aspx
The connection that the CLR procedure runs from is called the "Context Connection" and it is used like this:
using(SqlConnection connection = new SqlConnection("context connection=true"))
{
connection.Open();
// Use the connection
}
I wonder why you have to "open" the connection? I would think that the connection is already open since it is executing the procedure that is running.
Also closely related: http://msdn.microsoft.com/en-us/library/938d9dz2(v=vs.90).aspx
I created a backup of a database on sql server 200. I created a new database in sql server 2008 r2.
Now when i run a view i get the error :
'function_name' is not a recognized function name.
The function is there
And i can run it using
SELECT [dbo].[function_name] (
'hjh')
GO
SELECT dbo.function_name('kjk')
Why would this problem occur when it is functioning correctly originally?
EDIT:
I think it may be a security issue as schemas owned by the user under dbo does not contain antyhing?
Make sure you are executing it in the correct database context.
If the view is in Database2 and the function is in Database1 then you will need to fully qualify the function using the three part name:
Database1.dbo.[Function_Name]
All objects in a view are assumed to be in the same database as the view unless you specify otherwise.
Is the view on the same database as the function?
If they are not, you need to call it like [database_name].dbo.[function_name]