Can I import Mysql function and use it for multiple database with same pattern name without import that function any more ?
I know Mysql save function in two table :
information_schema.ROUTINES and mysql.proc
Does anyone have an idea to do this?
Every stored procedure is associated with its schema or database.
So long as the SPs are just routines but not depended on table data, one can happily call them from anywhere.
And if the SPs are intended to calculate based on table data, then you definitely need that database qualifier while defining the SP body.
I.e. instead of calling
select count(*) from routines;,
you require to call
select count(*) from information_schema.routines;.
If you look into the table structure of both routines and proc you can find a column routine_schema and db respectively which point to target database of the SPs.
Unless you define SP bodies, which are table data related, in this way
you definitely have to redefine them in your database environment.
More important thing is that, you again require privileges to access and execute such cross database SPs.
Related
For the sake of simplification, let's say I have 2 databases with data, db_data_1 and db_data_2 which have the same set of tables and I have a 3rd database where my stored procedures are defined, say db_sp. Let's say my stored procedure is called my_sp
When I try to call db_sp.my_sp from either db_data_1 or db_data_2, I get an error saying that the tables referenced in db_sp.my_sp don't exist.
How can I have db_sp.my_sp query the tables in the calling database vs the database where my_sp is defined (namely db_sp)
Thanks.
You must qualify the table names in your query with the database name in the stored procedure. SELECT col FROM db_data_1.tbl instead of SELECT col FROM tbl, for example.
The documentation says this:
USE statements within stored routines are not permitted. When a routine is invoked, an implicit USE db_name is performed (and undone when the routine terminates). The causes the routine to have the given default database while it executes. References to objects in databases other than the routine default database should be qualified with the appropriate database name.
Why is this so? It seems like a big pain in the xxx neck.
A big use of stored code is the hiding of data from unprivileged users. You can GRANT MySQL users access to stored procedures without granting access to the underlying tables. This restriction ties the tables to the procedures.
A user who has privileges only in the test database shouldn't be able to do this sort of thing.
USE production;
CALL test.get_all_user_private_data();
And, if you're USEing one database and you run stored code that's in a second database, it gets the data from that second database.
Your solution is to consider your stored code (procedures, functions) to be part of the schema definition for each database. They go along with your other data definition operations like CREATE TABLE. Don't try to put them in their own "code library" database, but put them in each database where they're needed.
I am having trouble running this query.
SELECT * FROM mysql.routines;
The error code 3554 says
Access to data dictionary table 'mysql.routines' is rejected.
I'm trying to look at all of my stored procedures. I've granted all privileges to the root user and it is still not working. Any ideas?
You seem to be looking for the INFORMATION_SCHEMA ROUTINES Table:
SELECT * FROM INFORMATION_SCHEMA.ROUTINES
From the documentation:
The ROUTINES table provides information about stored routines (stored procedures and stored functions). The ROUTINES table does not include built-in SQL functions or user-defined functions (UDFs).
In normal cases, it is recommended to use INFORMATION_SCHEMA instead of mysql schema : the former is the official interface to the system tables.
I just joined a team that's about to do some extensive modifications in our data-warehouse fact tables.
I have been assigned to modify all the procedures and functions that use them.
When I run the following query
SELECT * FROM mysql.proc
I get a list of the functions, procedures , in/out parameters that exist. But it doesn't show me what table(s) is/are in use in each function or procedure.
Several challenges:
naming convention is non existing so guessing is time-consuming
code that's out there is not in Git.
We have over 300 procedures and functions.
If all the code was in a file on my server, I would simply grep it for my table names. Is there a way to show what table(s) is/are in use in each function or procedure?.
We host multiple SQL Server 2008 databases provided by another group. Every so often, they provide a backup of a new version of one of the databases, and we run through a routine of deleting the old one, restoring the new one, and then going into the newly restored database and adding an existing SQL login as a user in that database and assigning it a standard role that exists in all of these databases.
The routine is the same, except that each database has a different name and different logical and OS names for its data and log files. My inclination was to set up an auxiliary database with a table defining the set of names associated with each database, and then create a stored procedure accepting the name of the database to be replaced and the name of the backup file as parameters. The SP would look up the associated logical and OS file names and then do the work.
This would require building the commands as strings and then exec'ing them, which is fine. However, the stored procedure, after restoring a database, would then have to USE it before it would be able to add the SQL login to the database as a user and assign it to the database role. A stored procedure can't do this.
What alternative is there for creating an automated procedure with the pieces filled in dynamically and that can operate cross-database like this?
I came up with my own solution.
Create a job to do the work, specifying that the job should be run out of the master database, and defining one Transact-SQL step for it that contains the code to be executed.
In a utility database created just for the purpose of hosting objects to be used by the job, create a table meant to contain at most one row, whose data will be the parameters for the job.
In that database, create a stored procedure that can be called with the parameters that should be stored for use by the job (including the name of the database to be replaced). The SP should validate the parameters, report any errors, and, if successful, write them to the parameter table and start the job using msdb..sp_start_job.
In the job, for any statement where the job needs to reference the database to be replaced, build the statement as a string and EXECUTE it.
For any statement that needs to be run in the database that's been re-created, doubly-quote the statement to use as an argument for the instance of sp_executesql IN THAT DATABASE, and use EXECUTE to run the whole thing:
SET #statement = #dbName + '..sp_executesql ''[statement to execute in database #dbName]''';
EXEC (#statement);
Configure the job to write output to a log file.
I was advised when executing a stored procedure, I should include the prefox dbo e.g.
exec dbo.'name_of_stored_procedure'
Does it matter if I don't include the prefix?
When should I use the prefix?
If your stored procedure is in the dbo schema, then you should say:
EXEC dbo.name_of_procedure;
Pros for specifying schema:
you know you're calling dbo.procedure even if there is also some_other_schema.procedure
the query engine doesn't have to go check your default schema for a similarly named object first
you don't get unpredictable results (e.g. if there is one in your schema but you meant dbo)
you have a better chance at query plan re-use if everyone consistently uses schema
Cons for specifying schema:
you type an extra four characters
What else does not being explicit buy you?
In SQL, it's best to be explicit and include the default schema [dbo] whenever you refer to objects, because later you may wish to define your own schemas which have stored procs or tables with the same name.
e.g.
dbo.sp_GetNames
Cities.sp_GetNames
Countries.sp_GetNames
dbo is not a prefix, is the schema
Schema are like groups, you can create a schema called Production and have your procedures like Production.AddStock and another called Sales and have procs like Sales.GetCustomer
They are specially good to manage permissions.
This link may help you:
http://msdn.microsoft.com/en-us/library/ms190387.aspx