What exactly this error is? - asp.net

Database i am using is MySQL 5.1. I specified, i believe, right connectionstring in my web.config. but when i run my web app. it throws this exception:-
MySql.Data.MySqlClient.MySqlException: The user specified as a definer ('root'#'%') does not exist
Any help. Why am i getting this?

The source code for the stored procedures that you have been loading probably contain "DEFINER=root#'%'" as part of the definition - looking a bit like this:
create definer='root'#'%' procedure sp_test() begin end;
The problem here is that you do not have an account on your system for 'root'#'%'. This can be easily demonstrated. From the MySQL command line:
show grants for 'root'#'%';
I expect that this will come back with an error message:
ERROR 1141 (42000): There is no such grant defined for user 'root' on host '%'
The fix is to alter the source of your stored procedures, or to create the missing account:
grant all on *.* to 'root'#'%' identified by 'password' with grant option;
It is not generally a good idea to have such a high-powered account accessible from anywhere, but that is another story.

I know this answer comes very late, but I found a solution that doesn't involve changing any rights at all.
Go into your Stored Procedures and delete the DEFINER clause. The server should write in a new DEFINER that matches the user information you're logged in with.
Worked for me...

Is this in a stored procedure? Then maybe this blog post helps (emphasis mine).
All the settings were fine and I was wondering what’s causing the problem. At first rush I thought that it could be a cache, as I had requested recently to have xcache on our server.
But it wasn’t the case. The error was much more stupid than even one can imagine. That specific script uses a stored procedure to insert / fetch data to/from MySQL. The user who had created the sp was the one who was deleted. And that was the problem. The term “Definer” in terms of MySQL is the one who creates the stored procedure and for the stored procedure to be executed that user must exists.

Related

Why would the TrackedMessages_Copy_BizTalkMsgBoxDb start failing with "Query processor could not produce a query plan"?

Why would the TrackedMessages_Copy_BizTalkMsgBoxDb SQL Agent job start failing with "Query processor could not produce a query plan"?
Query processor could not produce a query plan because of the hints defined in this query. Resubmit the query without specifying any hints and without using SET FORCEPLAN. [SQLSTATE 42000] (Error 8622).
Our SQL guys are talking about amending the stored proc. but we've told them to treat BizTalk db's as a black box
It should go without saying, but before anything, make sure to backup your databases. In fact, if your regular backup jobs are running, you may be able to restore a backup and compare things to when it was working on this server. That said -
Check the SQL Agent Job to make sure no additional steps have been added/no plan has been forced/no hints are being used; it should just have one step called 'Purge' that calls the procedure below with the DB server and DTA database name as parameters.
Check the procedure (BizTalkMsgBoxDb.dbo.bts_CopyTrackedMessagesToDTA) to make sure it hasn't been altered.
If this is a production or otherwise sensitive box, back up the DBs and restore them to a local dev environment before proceeding!
If this is not production, see if you can run the procedure (perhaps in a transaction that you rollback) directly in SSMS. See if you get any better errors. Add print statements to see if you can find out exactly where it's getting conflicting hints.
If the procedure won't run, consider freeing the procedure cache (DBCC FREEPROCCACHE) and seeing if the procedure will run.
If it runs in your dev environment from a backup, you may have to start looking at server/database settings. I can't think of which ones off the top of my head that would cause this error though.
For what it's worth, well intentioned DBAs break BizTalk frequently. They decide that an index is missing or not properly covering, or that security could be improved, or that the database should be treated like other databases they administer are treated. I've seen DBAs do really silly things to the BizTalk databases that get very hard to diagnose.
Did you try updating the statistics on the database table referenced by the stored procedure (which is run by the SQL Server Agent job? The query planner uses those to decide how best to execute your SQL.

"Could not find stored procedure <Proc Name Here>"

I am trying to add an control to my page. I am following the wizard. Step 1, I select my connection string. The connection works, no error messages. Step 2, I choose "Specify a custom SQL statement or stored Procedure" radio button. Step 3, in the "SELECT" tab I click the "Stored Prodedure" radio button, then select the stored procedure I would like to use. I take this as confirmation that the connection string is working. Step 4, I press the "Test Query" button.
A pop up appears with the message "There was an error executing the query. Please check the syntax of the command and if present, the types and values of the parameters and ensure they are correct. Could not find stored procedure .
I've tested the procedure in SSMS, and it works. I took the query string that is in the stored procedure and changed the radio from Step 3 to "SQL Statement" and pasted the string into the box. The statement worked fine.
I also changed the permissions for the login specified in the connection string to the same permissions I have on the server. (Full admin rights!) That did not correct the issue. I only found a few questions in the forums regarding this issue, and they all pointed to permission issues, but I have ruled that out as I set the permissions.
The Wizard can find the procedure when I am walking through the Wizard, but it can't find it when I test.
I hope someone can point me in the right direction... Thanks!
* EDIT *
Just to expand on the #BlackjacketMack's answer:
When I use the wizard to create the SqlDataSource, and select the Stored Procedure from the the list, it appears that VS is defaulting to the dbo schema at runtime, even though it displays all the sprocs in each schema. (I verified this by changing the schema the sproc was on to dbo and testing it. The results were returned with no errors.) Within the wizard, I do not see any options to change the schema. If I click the "SQL Statement" radio button and type EXECUTE [APP001].[MyStoredProcedure], it works perfectly. I did try the GRANT EXECUTE as #otaku recommended, but that did not work. I also changed the default schema for the user specified in the connection string to [APP001] to no avail. So this appears to be an issue when using the dropdowns in the wizard. Manually entering the data so that the schema can be fully qualified did the trick!
Make sure the application that you are running have the appropriate grant execute on the database objects. Sometimes they are tied to a database role such as below where the stored procedure need to have the execute permission:
GRANT EXECUTE ON ][dbo].[MyStoreProc] TO U_ExecuteProcs
Qualify your procedure with the schema If the proc has a schema 'APP001' as you indicated in a comment, make sure the Sql being passed looks something like EXEC APP001.YourStoredProcedureName.
Use a profiler! One great way to approach this problem is run a profiler on your SQL...either the MS Profiler, or we use http://anjlab.com/en/projects/opensource/sqlprofiler which used to be free. Basically, you'll see exactly what SQL your application is sending and who the login they're sending it as.
If you gave yourself admin permissions as you indicated, I wouldn't define too many object specific permissions simply because they tend to go unmaintained.
I think defining the execution context within your stored procedure will resolve the issue , Here is the link:
http://technet.microsoft.com/en-us/library/ms188354.aspx

SP Not Found When It Clearly Exists

I copied a database from a live MSSQL server to my local one, and was able to log in correctly. I am having a problem however in that when it is time to call a stored procedure the Asp.Net application keeps telling me the SP does not exist, when it clearly does.
I am using windows authentication but on the server I was using credentials, could this be the problem?
Also, all of the SP's have my online username attached to their name, as in username.StoredProcedurenName.
Please help I have been trying to fix this for hours.
I just noticed that when I attempt to run the SP from the SQL Management Studio it works, but it appends the username to the SP such as:
USE [DBNAME]
GO
DECLARE #return_value int
EXEC #return_value = [username].[SPNAME]
SELECT 'Return Value' = #return_value
GO
If I remove the username, it says the same thing (SP not found). How do I get around this?
I suspect you are calling your stored procedure without specifying the schema. When calling a stored procedure (or accessing a table, view, etc) that's not in the default schema that your account is configured for, usually dbo, you need to explicitly include the schema like the sql command below
SqlCommand cmd = new SqlCommand("username.StoredProcedurenName", mySqlConnection);
It's likely what Jason said. The solution has to do with rights and ownership. When you see the SP in the SQL Management Studio, under Programmability->Stored Procedures, your SP should have a prefix like "dbo." or "GateKeeper."
If the SP has "dbo." as the prefix, the user account with which you're connecting to the DB just be part of the database owners (dbo) group, otherwise you won't have access to it. So, you can either add the user to that group, or create the stored procedure ("create procedure spBlahBlah as ..") using the account to plan to run the program under; when you call it you use "exec GateKeeper.spBlahBlah" to stipulate the Schema.StoredProcedureName.
Those are your two choices.

Qt - How to list all existing databases on PostgreSQL server using Qt interface

Could someone please explain how to obtain a list of all existing databases on a PostgreSQL server, to which the user already has access, using Qt? PostgreSQL documentation suggests the following query:
SELECT datname FROM pg_database WHERE datistemplate = false;
What are the correct parameters to the following functions:
QSqlDatabase::setDatabaseName(const QString & name) //"postgres" or "pg_database"?
QSqlDatabase::setUserName(const QString & name) //actual user name?
QSqlDatabase::setPassword(const QString & password) //no password? or user password?
Much appreciated. Thank you in advance.
You appear to have already answered the first part of your question. Connect to the postgres or template1 database and issue the query you've quoted above to get a list of databases. I'm guessing - reading between the lines - that you don't know how to connect to PostgreSQL to send that query, and that's what the second part of your question is about. Right?
If so, the QSqlDatabase accessor functions you've mentioned are used to set connection parameters, so the "correct" values depend on your environment.
If you want to issue the query above - to list databases - then you would probably want to connect to the postgres database as it always exists and isn't generally used for anything specific, it's there just to be connected to. That means you'd call setDatabaseName("postgres");. Passing pg_database to setDatabaseName would be nonsensical, since pg_database is the pg_catalog.pg_database table, it isn't a database you can connect to. pg_database is one of those odd tables that exists in every database, which might be what confused you.
With the other two accessors specify the appropriate username and password for your environment, same as you'd use for psql; there's no possible way I could tell you which ones to use.
Note that if you set a password but one isn't required because authentication is done over unix socket ident, trust, or other non-password scheme the password will be ignored.
If this doesn't cover your question, consider editing it and explaining your problem in more detail. What've you tried? What didn't work how you expected? Error messages? Qt version?

Automatic fix for tempdb error related to 'ASPStateTempSessions'

As per this how-to, I've successfully configured IIS on my XP-SP3 dev box for SQL Server 2008 Express to save ASP.NET session state information. I'm just using SQL Server because otherwise on every recompile, I was losing the session state which was obnoxious (having to re-login). But, I'm facing an annoying issue in that every time I restart SQL there's this error, and sometimes one or two other very similar friends:
The SELECT permission was denied on the object 'ASPStateTempSessions',
database 'tempdb', schema 'dbo'.
To fix the error, I just open Management Studio and edit the User Mapping for the login/dbo I'm using on the ASPState db, and re-add tempdb to that user with all but deny permissions. Apparently, once the right permissions are there, ASP.NET is able to automatically create the tables it uses. It just can't run that CreateTempTables sproc until the right security is there.
THE QUESTION...
Is there a way to not have to re-do this on every restart of the SQL Server?
I don't really care right now about keeping the temp data across restarts, but I would like to not have to go through this manual step just to get my web app working on localhost, which uses session state variables throughout. I suppose one could resort to some kind of stored procedure within SQL Server to accomplish the task for this machine when the service starts, to not have to do it manually. I'd accept such an answer as a quick fix. But, I'm also assuming there's a better recommended configuration or something. Not seeing an answer to this on the how-to guide or elsewhere here on StackOverflow.
Both answers seem valid; but with most things Microsoft, its all in the setup...
First uninstall the ASPState database by using the command:
aspnet_regsql –ssremove –E -S .
Note:
-E is to indicate you want to use integrated security connection.
-S informs what SQL server and SQL instance to use, and the "." (dot) specifies default local instance
Then re-install using the command:
aspnet_regsql –ssadd –sstype p –E -S .
Note:
The sstype has three options, t | p | c ... the first "t", tells the installer to host all stored procedures in the ASPState database, and all data in the tempdb. The second option "p" tells the installer to persist data to the ASPState database. The last option "c" allows you to specify a different 'custom' database to persist the session state data.
If you reinstall using the "-sstype p" you then need only to supply datareader/datawriter to the ASPState database for the user that's making the connection (in most cases, the application pool's identity in IIS).
The added benefit of persisting the data is that session state is retained even after a restart of the service. The only drawback is that you need to ensure the agent cleanup job is pruning old sessions regularly (it does this by default, every minute).
Important:
If you are running a cluster, you must persist session data. You're only option is to use sstype 'p' or 'c'.
Hope this sheds light on the issue!
For the record, I did find a way to do this.
The issue is that the tempdb is recreated from the model db each time the service restarts. The gist of the solution is to create a stored procedure that does the job, and then make that procedure run at startup.
Source code (credit to the link above) is as follows:
use master
go
-- remove an old version
drop proc AddAppTempDBOwner
go
-- the sp
create proc AddAppTempDBOwner as
declare #sql varchar(200)
select #sql = 'use tempdb' + char(13) + 'exec sp_addrolemember ''db_owner'', ''app'''
exec (#sql)
go
-- add it to the startup
exec sp_procoption 'AddAppTempDBOwner', 'startup', 'true'
go
Well done for finding the strangest way possible to do this.
The correct answer is as follows:
use master
go
EXEC sp_configure 'Cross DB Ownership Chaining', '1'
go
RECONFIGURE
go
EXEC sp_dboption 'ASPState', 'db chaining', 'true'
go

Resources