 |
|
 |
When using the code below, I got the message:
Could not find stored procedure 'sp_xxx'
The database open is OK
The SP exist.
Using .Net 3.5 and SQL Server 2005
Hope anybody can help me.
Thanks in advance.
The code:
SqlConnection Connection = new SqlConnection(
@"Data Source=" + Utility.str_Server +
"Initial Catalog=" + Utility.str_Catalog);
Connection.Open();
SqlCommand Command = new SqlCommand("SP_Login", Connection);
Command.CommandType = CommandType.StoredProcedure;
Command.Parameters.Add("@name", SqlDbType.NVarChar, 50).Value = Utility.var_Brugernavn;
Command.Parameters.Add("@password", SqlDbType.NVarChar, 50).Value = Utility.var_Kodeord;
// OUTPUT parametre
SqlParameter param2 = new SqlParameter("@accessLevel", SqlDbType.Int, 0, ParameterDirection.Output, false, 0, 0, "accessLevel", DataRowVersion.Default, null);
Command.Parameters.Add(param2);
SqlParameter param3 = new SqlParameter("@UserID", SqlDbType.Int, 0, ParameterDirection.Output, false, 0, 0, "UserID", DataRowVersion.Default, null);
Command.Parameters.Add(param3);
if ( ConnectionState.Open == Connection.State )
{
Command.Connection = Connection;
try
{
Command.ExecuteNonQuery();
Utility.var_pwLevel = Convert.ToUInt32(((SqlCommand)Command).Parameters["@accessLevel"].Value);
Utility.var_UserID = Convert.ToUInt32(((SqlCommand)Command).Parameters["@UserID"].Value);
return true;
}
catch (Exception e)
{
//Send the exception to our exception label
//this.lblException.Text = exc.ToString();
Console.WriteLine(e.ToString());
return false;
}
finally
{
Connection.Close();
}
}
else
{
return false;
}
}
|
|
|
|
 |
|
 |
Thanks for your effort
Discover Other ....
http://www.islamHouse.com
|
|
|
|
 |
|
 |
The SQL code you have will return 2 records for a parameter of type NVARCHAR. Change it to:
inner join systypes t on s.xtype = t.xusertype
Thanks for the article.
|
|
|
|
 |
|
 |
How do you handle the case when the stored procedure is more than 4000 characters?
Some of my procedure text is getting chopped off after 4000 characters
|
|
|
|
 |
|
 |
The name of your stored procedure is over 4000 characters long?! If that's what you're saying, I'm not sure it's possible. The datatype for the [name] column in sysobjects is sysname, which is a user-defined datatype that is used in the system tables whose definition is varchar(30) "NULL". So, I'm not sure how a 4,000 character SP name would fit into that column...
If your talking about the stored procedure text, I'm not enumerating that in this example, so you must have changed something in the code. This example enumerates names and parameters of stored procedures. If you have a name or a parameter name > 4000 characters...well...I don't know what to tell you...
Quae narravi nullo modo negabo.
|
|
|
|
 |
|
 |
Yes I had changed it to retrieve the text of the stored procedure,
I was hoping for an automated way to track the changes to the stored procs across multiple databases but it seems if the stored proc is more than 4000 characters it gets truncated.
I figure it is kept somewhere .. I am in the process of tracking it down.
|
|
|
|
 |
|
 |
I recommend to use sp_sproc_columns to get parameter info.
Jan van der Kruyk
|
|
|
|
 |
|
|
 |
|
 |
Thats true but sometimes the sql is better in certain situations.
Probably the best example is if you were making a tree control that listed db items. sp, vw, tbl for a given database, but not just for mssql.
different databases will have a different hash other than ['PROCEDURE_NAME']
being able to use "AS" in plain sql will allow u to do something like this
while (reader.Read())
{
TreeNode spNode = new TreeNode(reader["STORED_PROCEDURE_NAME"].ToString(), 2,2);
parentNode.Nodes.Add(spNode);
}
where the reader contains data from mssql or mysql or ...
Although this is a specific example the example presented here is not obsolete. [i'm sure there are other reasons]
but yes i agree for simple use the sp is a good idea...way easier to remember
Object type. Can be one of these values:
C = CHECK constraint
D = Default or DEFAULT constraint
F = FOREIGN KEY constraint
FN = Scalar function
IF = Inlined table-function
K = PRIMARY KEY or UNIQUE constraint
L = Log
P = Stored procedure
R = Rule
RF = Replication filter stored procedure
S = System table
TF = Table function
TR = Trigger
U = User table
V = View
X = Extended stored procedure
another reason is for furthur filtering: consider the possible functions: IF, FN, TF
or stored procedures RF, X, P... you can't modify the where cause easily if your running an sp.
Leblanc Meneses
http://www.blogsyndrome.com
http://www.robusthaven.com
-- modified at 4:59 Thursday 20th July, 2006
|
|
|
|
 |
|
 |
You should never pull data directly from the sys... tables in a SQL Server database. That's what the INFORMATION_SCHEMA views exist for. (As Michael indicated.)
The system tables in a SQL Server database are undocumented for a reason. This gives Microsoft the ability to completely restructure the tables and their usage as they see fit from one SP to the next, and if it blows up someone's code (that did something along the lines of your article), then it's their own fault for selecting from undocumented data structures.
You should seriously consider looking into the INFORMATION_SCHEMA views and re-write your article to use that, instead.
(BTW, there's a function in SQL Server called object_id() that will give you the identity of an object in the database for use with other functions that require the object id.)
Grim (aka Toby) MCDBA, MCSD, MCP+SB
SELECT * FROM users WHERE clue IS NOT NULL
GO
(0 row(s) affected)
|
|
|
|
 |
|
 |
Good to know for the next release of MSSQL Server, post 2005.
This solution works fine for MSSQL 2000-2005, and in all likelihood will continue to do so (to the best of my knowledge, MS hasn't deleted anything from system tables since before MSSQL 7).
Granted, Microsoft recommends querying from INFORMATION_SCHEMA (as has now been pointed out twice), however, the likelihood of the system tables changing their schema any time soon is rather slim. If you consider that the INFORMATION_SCHEMA views themselves, as well as a great many stored procedures and extended stored procedures utilize the system tables to glean data, either enumeration method should be more than acceptable. I'll take Michael's perspective as this being an 'Alternate Method', rather a 'Bad Idea'.
So, in conclusion, I'll rewrite the article when MS changes their system tables in a service pack.
Quae narravi nullo modo negabo.
|
|
|
|
 |
|
 |
"So, in conclusion, I'll rewrite the article when MS changes their system tables in a service pack."
Are you also going to re-write and re-distribute software for everyone whose applications break because they followed your advice and used undocumented system tables?
Grim (aka Toby) MCDBA, MCSD, MCP+SB
SELECT * FROM users WHERE clue IS NOT NULL
GO
(0 row(s) affected)
|
|
|
|
 |
|
 |
No need to get bent out of shape, Toby. My comment was meant to be facetious, in that the system tables don't frequently change. You disagree with my method of doing things, and that's your prerogative, but it doesn't make my method wrong. Anyone who decides to read this article will also see your and Michael's input, and they can decide how they want to do things, that's the beauty of an open forum.
I'm not going to change my article, because nowhere in my article did I state it was the hands-down-best way of doing it...I provided a solution to enumerate through SQL stored procedures, and the solution does exactly that for VS.NET 2003 and MSSQL 2000, which is the audience for which I wrote.
You are more than welcome to write an article of your own (I see that you have none so far, so perhaps this is a good place to start?), and tout the benefits of utilizing INFORMATION_SCHEMA views as opposed to system tables.
I take no responsibility for anyone who cuts and pastes code into their application without first reading the commentary, or exploring different methodologies. So, in answer to your question, no, I won't.
Cheers.
Quae narravi nullo modo negabo.
|
|
|
|
 |
|
 |
Heh,
That would be true in case if Information_Schema returned always results that are required.
If you'll do deeper investigation how that view is defined, you'll find that for example: it doesn't always return full stored procedure body in case if stored procedure has quite long definition.
Then stored procedure is defined on multiple lines in syscomments table, so such-a defined column from
inf. schema table doesn't have a chance to get the full definition, but it will cut it somewhere in the middle.
As far as i know, to look directly into syscomments table is the only way then how to get what i need.
definition from information_schema table :
ROUTINE_DEFINITION = convert(nvarchar(4000),
(SELECT TOP 1 CASE WHEN encrypted = 1 THEN NULL ELSE com.text END
FROM syscomments com WHERE com.id=o.id AND com.number<=1 AND com.colid = 1))
That i.e. direct look will get better results then microsoft defined view and therefore i prefer looking into table where the data is defined and get it correctly even if in future there is some tiny chance that the structure will change.
Best regards,
Jaroslav ala Yarex ala yarex@pobox.sk
|
|
|
|
 |
|
 |
I liked your article, and wanted to let you know of another approach you might consider. A while back I stumbled across the INFORMATION_SCHEMA views. These are part of the SQL-92 standard (nice summary here[^])and as such the views will be available not only in SQL 2000, but also other databases. Since Microsoft doesn't recommend querying system tables as they are "subject to change", this is a great alternative.
For your sample, you would want to iterate through the procedures via:
SELECT * FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_TYPE = 'PROCEDURE' ORDER BY ROUTINE_NAME
Then get the parameters with this:
SELECT PARAMETER_NAME, DATA_TYPE, CHARACTER_MAXIMUM_LENGTH
FROM INFORMATION_SCHEMA.PARAMETERS
WHERE SPECIFIC_NAME = << PROCEDURE NAME >> ORDER BY ORDINAL_POSITION
You can't get the object Id this way, but if you explore some of the other data availble via these views, it's pretty extensive and a bit more user friendly than the system tables.
Mike
|
|
|
|
 |
|
 |
There's a function in SQL Server called object_id('object_name') that will give you the identity of an object in the database for use with other functions that require the object id.
Grim (aka Toby) MCDBA, MCSD, MCP+SB
SELECT * FROM users WHERE clue IS NOT NULL
GO
(0 row(s) affected)
|
|
|
|
 |
|
 |
Thank you. Just what I needed for my current project. By the way, it converted to 2005 with no problems.
|
|
|
|
 |
|
 |
Good deal. I figured it probably would, but since I don't have a dev environment setup for 2005, I didn't want to say it did until I could test. Glad it helped out.
Quae narravi nullo modo negabo.
|
|
|
|
 |